Package Details: photoview 2.3.13-1

Git Clone URL: https://aur.archlinux.org/photoview.git (read-only, click to copy)
Package Base: photoview
Description: Photo gallery for self-hosted personal servers
Upstream URL: https://github.com/photoview/photoview
Licenses: AGPL3
Conflicts: golang-photoview
Replaces: golang-photoview
Submitter: feinedsquirrel
Maintainer: feinedsquirrel (edpibu)
Last Packager: edpibu
Votes: 3
Popularity: 0.000000
First Submitted: 2021-06-10 18:05 (UTC)
Last Updated: 2022-07-31 15:33 (UTC)

Dependencies (17)

Required by (0)

Sources (2)

Latest Comments

1 2 Next › Last »

feinedsquirrel commented on 2024-02-07 06:33 (UTC) (edited on 2024-02-07 06:33 (UTC) by feinedsquirrel)

@krutoileshii

try adding PATH=/usr/bin:/usr/bin/vendor_perl to the [Service] section of the photoview.service file. That may allow it to load exiftool.

As for darktable, I was never able to dedicate enough time to it. Try creating manually the two files @agrueneberg shows.

krutoileshii commented on 2024-02-07 04:40 (UTC)

Not sure what i'm missing on the exiftool. Added the Environment variable... still complaining

Feb 06 20:40:10 archlinux photoview[265270]: 2024/02/06 20:40:10 Error initializing ExifTool: error when executing command: exec: "exiftool": executable file not found in $PATH Feb 06 20:40:10 archlinux photoview[265270]: 2024/02/06 20:40:10 Failed to get exiftool, using internal exif parser instead: error when executing command: exec: "exiftool": executable file not found in $PATH

Here is the override: [Service] Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/vendor_perl

Also @agrueneberg, how do I use the sysusers.d portion? manually make a folder and file or through systemd-user

agrueneberg commented on 2023-03-10 09:47 (UTC)

I solved the darktable issue using tmpfiles and sysusers overrides:

/etc/tmpfiles.d/photoview.conf

d     /home/photoview  0755 photoview photoview 10d -

/etc/sysusers.d/photoview.conf

u photoview - "photoview user" /home/photoview

Alternatively, changing $HOME to some writable temporary location in photoview.env might also work.

That said, I think this kind of solution is too ugly to include just to make an optional dependency work...

I looked into fixing the problem upstream: darktable allows to --configdir and --cachedir to be changed, but darktable-cli doesn't process these arguments when used with --version (as called by photoview) and uses the defaults instead 🤷

feinedsquirrel commented on 2023-03-04 07:18 (UTC)

Regarding exiftool, see issues #730 and #787. I will try to fit in the time this month to work with upstream to properly fix that issue.

Regarding the darktable integration, that may point to why my test installation was failing to find it, though I failed to diagnose. I thought the issue I had was regarding paths, as with exiftool. Off the top of my head, the easiest thing would be to create a darktable config and cache directory with tmpfiles, but I'm not sure if that is kosher, or if it would even work. I'll have to look up darktable docs, and see if they support a non-home-directory location for cache and config.

Beyond that, I'll try to find some arch documentation to see if the tmpfiles solution is acceptable Arch practice for that, and I'll ask on IRC as well, to see what the best solution would be for that.

If you have any ideas, feel free to voice them. We'll see what we can come up with.

agrueneberg commented on 2023-02-28 13:39 (UTC)

Darktable integration is not working:

Error getting version of darktable: exit status 1

darktable tries to open ~/.config/darktable and ~/.cache/darktable on startup, but the photoview user does not have an explicit home directory:

$ sudo -u photoview darktable-cli
path lookup '/.config/darktable' fails with: 'No such file or directory'

Any good ideas on how to fix this?

agrueneberg commented on 2023-02-27 13:01 (UTC) (edited on 2023-02-28 12:12 (UTC) by agrueneberg)

I had to add a PATH override for photoview to find /usr/bin/vendor_perl/exiftool:

[Service]
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/vendor_perl

feinedsquirrel commented on 2021-10-13 15:23 (UTC)

Sure thing! And, I think you are added now. Let me know if I didn't do it right.

One thing I'm thinking is to try to figure out how to fix a bunch of the "deprecated package" messages in the upstream code. If you are familiar with npm and such, and would like to help/teach me how to do so, let me know. Also, if you have other suggestions with changes for the arch packaging, let me know, I'd love to learn.

edpibu commented on 2021-10-13 10:39 (UTC)

No problem @feinedsquirrel ! I would appreciate it if you can add me as a co-maintainer. Thanks for the answer and for updating the package !

feinedsquirrel commented on 2021-10-13 03:13 (UTC)

@edpibu, I apologize for the late response. I try to get around to this about once per month. If that isn't often enough, I'm happy to transfer ownership, or, add you as a co-maintainer. I appreciate the note about husky. One benefit of waiting was that the husky issue was apparently solved upstream, as I didn't have to address it directly, but I was able to build 2.3.8 without any specific changes. What has changed is the developer accepted my request to upstream the systemd files I created.

edpibu commented on 2021-09-19 13:20 (UTC)

The package does not build anymore because of husky:

> (cd .. && npx husky install)

.git can't be found (see https://git.io/Jc3F9)

A temporary fix is to delete the .git folder at the package root after cloning, or to revert to the previous version (2.3.5).

1 2 Next › Last »