Arch Linux User Repository

Important Note on AUR packages in general:

For AUR packages, you - as the user installing the package - assume the role that a package maintainer has for regular repo packages.

That means that the responsibility to recompile the package whenever a package B that your package depends on changes. For repo packages, maintainers do this for you and re-release the package with an updated build number (e.g. -1 to -2). AUR mainainers will not do this, because there is no change to the PKGBUILD. You need to recompile locally, whenever this happens.

Important Note on AUR packages in general:

For AUR packages, you - as the user installing the package - assume the role that a package maintainer has for regular repo packages.

That means that the responsibility to recompile the package whenever a package B that your package depends on changes. For repo packages, maintainers do this for you and re-release the package with an updated build number (e.g. -1 to -2). AUR mainainers will not do this, because there is no change to the PKGBUILD. You need to recompile locally, whenever this happens.

@sultanoswing: I should probably sticky this, but here goes again: If a package, that an AUR package depends upon receives a major (i.e. ABI/API breaking) update, you need to rebuild the AUR package afterwards. This is what package maintainers do, and for your AUR packages, that's you. So I'd advise against symlinking anything, and to instead do the right thing: Rebuild!

Another heads up - wouldn't start after latest libvpx update with the error: "mythfrontend: error while loading shared libraries: libvpx.so.5: cannot open shared object file: No such file or directory".

Workaround: ln -s /usr/lib/libvpx.so.6 /usr/lib/libvpx.so.5

Just a heads-up: x265 updated to a new version, so you'll probably want to rebuild...

@Taijian If you put libhdhomerun in make dependencies, you must not tag it optional. libhdhomerun will be linked with the binary /usr/bin/mythtvfrontend and mythbackend : $ ldd /usr/bin/mythfrontend |grep home libhdhomerun.so => /usr/lib/libhdhomerun.so (0x00007f7110611000)

Turns out that the unstable, hanging clients were due to a crashed server. The crash most likely occurred during one client (archlinux and libxnvctrl) attempting to change the clients's theme. Rebooting the server resolved the problem, the server is remote thus the delay. I apologize for any confusion. It would seem that the jump from 0.29 to 0.30 might have been a little premature. I see that I am no longer able to go 'Watch Recording'→'Recordings(all)' then ← 'Recordings (title)' on most recordings where a graphic is displayed instead of the list of 'Recording Titles'. This is in theme 'Mythbuntu 28.21'.

@keepitsimpleengr: So, I'm a little confused as to which of your clients is the stable one? Maybe there's hint to the source of the problem there? Also, without some sort of detail, I can't really tell what the problem might be.

After the 2019-01-17 update, three of my four mythfrontend clients are unstable and tend to hang. One uses manjaro and libxnvctrl-390xx; another drives a TV using HDMI, uses archlinux and libxnvctrl-390xx; and the third uses archlinux and libxnvctrl. The fourth is backend/frontend (myth)buntu using development 0.30 from repository http://ppa.launchpad.net/mythbuntu/30/ubuntu on Ubuntu 16.04.5 LTS. I jumped to the Dev repository to keep database compatibility with AURs 1:30.0-3, mythbuntu repository still at 0.29. The mythbuntu server dates back to 10... LTS. No logs on these frontends.

thx :-)))

From two remote clients $ mythfrontend mythfrontend: error while loading shared libraries: libXNVCtrl.so.0: cannot open shared object file: No such file or directory Fixed by installing libxnvctrl-390xx.