Package Details: plex-media-server-plexpass 1.32.7.7571-1

Git Clone URL: https://aur.archlinux.org/plex-media-server-plexpass.git (read-only, click to copy)
Package Base: plex-media-server-plexpass
Description: The back-end media server component of Plex.
Upstream URL: https://plex.tv/
Keywords: DLNA
Licenses: custom
Conflicts: plex-media-server
Provides: plex-media-server
Submitter: miffe
Maintainer: fryfrog (tixetsal)
Last Packager: fryfrog
Votes: 140
Popularity: 0.180288
First Submitted: 2014-10-16 20:13 (UTC)
Last Updated: 2023-09-27 20:50 (UTC)

Pinned Comments

fryfrog commented on 2023-09-18 18:00 (UTC)

I think that only works when the version is the same, not lower. I don't think my intention is to force everyone to downgrade, rather new installs won't have the hardware transcoding issues and anyone w/ the issue may hopefully notice the weirdness and have a look and decide to downgrade if they like. Hopefully, they fix it soon and this will all be a moo point.

fryfrog commented on 2023-09-18 17:52 (UTC)

@yochananmarqos, I know, right? Once they sort this out, we'll get a new, higher version. I don't have any HDR hw transcoding, so I don't plan on downgrading personally.

Latest Comments

1 2 3 4 5 6 .. 35 Next › Last »

bkb commented on 2023-09-18 18:54 (UTC)

2 years 5 months 3 weeks 5 days 13 hours 52 minutes later

yochananmarqos commented on 2023-09-18 18:31 (UTC) (edited on 2023-09-18 18:33 (UTC) by yochananmarqos)

@fryfrog: Technically, an epoch should have been used; however in this case I'd say leave it as is as I agree with your reasoning.

See: https://wiki.archlinux.org/title/PKGBUILD#epoch

fryfrog commented on 2023-09-18 18:22 (UTC)

@mmozeiko, you're totally right! I'd never seen epoch and my mind just converted that to pkgrel, sorry! I don't think we need to use that in this case, but I'll tuck it away for serious business in the future. Thanks!

mmozeiko commented on 2023-09-18 18:14 (UTC)

Epoch value overrides any version comparison. See this from pacman's man:

Additionally, version strings can have an epoch value defined that will overrule any version comparison, unless the epoch values are equal. This is specified in an epoch:version-rel format. For example, 2:1.0-1 is always greater than 1:3.6-1.

fryfrog commented on 2023-09-18 18:00 (UTC)

I think that only works when the version is the same, not lower. I don't think my intention is to force everyone to downgrade, rather new installs won't have the hardware transcoding issues and anyone w/ the issue may hopefully notice the weirdness and have a look and decide to downgrade if they like. Hopefully, they fix it soon and this will all be a moo point.

mmozeiko commented on 2023-09-18 17:58 (UTC)

I believe forced version downgrade requires using epoch version: https://wiki.archlinux.org/title/PKGBUILD#epoch

fryfrog commented on 2023-09-18 17:52 (UTC)

@yochananmarqos, I know, right? Once they sort this out, we'll get a new, higher version. I don't have any HDR hw transcoding, so I don't plan on downgrading personally.

yochananmarqos commented on 2023-09-18 17:29 (UTC)

@fryfrog: 1.32.5.7516-1 < 1.32.7.7484-1. Wot’s… Uh the Deal?

fryfrog commented on 2022-12-05 23:35 (UTC)

@erylflynn: Have you tried it w/o that parameter? I'm like 85% sure it is not preserving the owner of the files during packaging, like where you run makepkg. Otherwise, they'd end up owned as your user since the build and package stage runs as you.

What use case is there for the package files not to be owned by root, as is good and proper and ordained by god? I can see having the data itself owned by another user (in fact, it should be plex for everyone).

erylflynn commented on 2022-12-05 23:23 (UTC)

Curious, in the package build for the cp step you have the --no-preserve set for ownership. In some cases it is better to run the plex service as a different user, and with this it would overwrite the owner every time you update.

Is there a bigger reason or can that be dropped from the package build?

1 2 3 4 5 6 .. 35 Next › Last »