Troubleshooting Shared libs required for third party package

B

boris_net

Hi all,

I am trying to understand how to troubleshoot an issue I have with a third party package in a jail.

In short, I have two jails, emby and emby2, both setup on 11.2-RELEASE and created using iocage on zfs dataset.
In the emby jail, I have the third party emby-server package installed using their recommended steps however I face the following:
Code: 
pkg info emby-server
emby-server-3.5.2.0_1
Name           : emby-server
Version        : 3.5.2.0_1
Installed on   : Fri Aug 24 23:26:35 2018 EDT
Origin         : multimedia/emby-server-3.5.2.0
Architecture   : FreeBSD:11:amd64
Prefix         : /usr/local
Categories     : multimedia
Licenses       : UNKNOWN
Maintainer     : apps@Emby.media
WWW            : UNKNOWN
Comment        : Emby Server is a personal media server with apps on just about every device
Shared Libs required:
    libwebpmux.so.3
    libX11.so.6
    libzvbi.so.0
    libtheoraenc.so.1
    libxcb-shape.so.0
    libxcb-xfixes.so.0
    libopus.so.0
    libfribidi.so.0
    libfreetype.so.6
    libvorbisenc.so.2
    libx264.so.152
    libxcb-shm.so.0
    libwebp.so.7
    libva-x11.so.2
    libvorbis.so.0
    libva-drm.so.2
    libiconv.so.2
    libfontconfig.so.1
    libgnutls.so.30
    libass.so.9
    libxcb.so.1
    libtheoradec.so.1
    libva.so.2
    libsmbclient.so.0
Shared Libs provided:
    libswscale.so.5
    libavutil.so.56
    libavfilter.so.7
    libavcodec.so.58
    libmp3lame.so.0
    libSkiaSharp.so.60
    libavdevice.so.58
    libavformat.so.58
    libswresample.so.3
    libpostproc.so.55
Annotations    :
    FreeBSD_version: 1102000
Flat size      : 57.1MiB
Description    :
Emby Server is a personal media server with apps on just about every device

If I try to add some packages for some of the libs listed under required, it looks like they are installed:
Code: 
root@emby:~ # pkg install libx264
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
The most recent version of packages are already installed

root@emby:~ # pkg install libass
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The most recent version of packages are already installed

root@emby:~ # pkg install libx11
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The most recent version of packages are already installed

In emby2, I have the FreeBSD package which works fine for the playback but is missing a fix which is in the third party package above.

Could somebody help me understand what could be missing in the third party package that would prevent the libs to be seen as provided and currently reported as 'required'?

I have a thread with the folks having built the third party emby package with the fix I need for LiveTV however I am missing the playback since ffmpeg and ffprobe are missing libraries. More details are available here: https://emby.media/community/index....-object-library-not-found-for-ffmpeg-on-3602/

For this thread, I would like guidance on how to troubleshoot third party package to understand what could triggered the list of Shared libraries required while packages for these libraries look like being installed.

Thanks in advance.
 
How sure are you that those instructions apply to modern versions of FreeBSD?

Sorry for a personal rant, but here comes a personal rant:

This is why I never trust blog posts which don't even bother to try and date stamp their work. Obviously the author never managed to grasp that one most important aspect: things change over time, and in order for your target audience to know you should make sure that they realize when you wrote what you did. Time stamp your work.

That obviously doesn't apply here. No, no, no: don't get fooled by that moronic "(C) 2018 Emby LLC" at the bottom: that means nothing. It's just part of the general template and only added to protect their own personal intellectual property. That seems more important than trying to give your target audience information they can actually use..

Sorry, but this isn't just a rant. I actually followod your steps (this link here) and the moment I landed on that GitHub page I realized I ended up with crap. No date stamp, no indication what so ever what FreeBSD version they were targeting, you don't even get easy access to older releases. Sorry: that is plain out crap in my opinion.

Your problem isn't with FreeBSD, it's with this product which apparently doesn't know how to properly support an operating system.

Yes, I am very skeptic and full of criticism, that's because

1) I started a rant
2) I did my homework

Let's compare this mockery of "we support open source environments" with their Windows download page: "Supports Windows 7 SP1 or newer version of Windows. If running Windows 7 please make sure Windows Updates are fully up to date.". How easy can it be?

Isn't it peculiar how they only seem to support Ubuntu Linux (source here) even though there is much more about Linux beyond that? Also: isn't it peculiar how they never mention which version of Ubuntu they're actually supporting? Do they even know what the heck they're doing? I have my doubts.

</rant>

Sorry, but seeing stuff like that sometimes gets to me. Especially when its giving free environments such as Ubuntu and FreeBSD a bad name. I really don't have much respect for projects like that.

Alas: I cannot conclude otherwise that your problem is with this (semi-commercial) project. There really isn't much we can do or say here. It depends on ports, it never bothers to tell us what FreeBSD version it is targeting which makes it everyones guess what these guys were thinking.

All sarcasm put aside: you should ask this on their support forums too, not just this one. I'm not trying to be overly annoying or anything but given the lack of any useful information there's nothing we can do here. Only they know what version of the OS (and the ports) they targeted.

See: for all I know this could be targeted for 11.2, however 104 is still supported and some ports can cause slight issues if you try to use them on 11.2 due to the version "mismatch". Please note: I am not claiming that this is the cause of your problem, I simply don't know (there isn't enough info for those conclusions) but given the lack of any useful information on their blog (and them not even bothering to mention which FreeBSD version(s) they support) I can't help but wonder if this could be causing issues. It has for general FreeBSD usage (binary drivers which people try to use on 11.2 while they're build for 10.4).

You should really present this problem on their forums and ask them which FreeBSD version they actually support. And don't accept "all modern versions" or any of that marketing nonsense: ask them to be specific: what version?

I'm decently confident that this could help you resolve this issue.
 
I did not expect such a long and off topic viewpoint on the project itself. I have not stated FreeBSD has or is the problem. I am well aware of the challenges associated to such projects. I was looking for guidance on package troubleshooting since it is obvious there is not much useful information associated to the custom package while the official package has the playback feature working.

The fact that version 3.5.2 of the FreeBSD package works on 11.2-RELEASE vs the custom 3.5.2 from their github fails to have a fundamental feature working on 11.2-RELEASE is what got me thinking.

I will reiterate my question to avoid confusion.

Project/package aside, in a generic manner, what is the reason for libraries to be listed under Shared libraries required while they have been installed through a generic package already. I am trying to understand the linkage that may happen in a package. I am asking as I have never built a package before and curious to better understand the generic mechanics and the potential reason why that may happen. Again, I am not looking for a direct solution but really a better understanding of the packaging logic in FreeBSD.
 
If you see a shared library required by port/package you can trust that there is a package that provides that shared library, the only exceptions are the base system libraries. For example:

Code: 
% ldd /usr/local/bin/git
/usr/local/bin/git:
        libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x800a47000)
        libz.so.6 => /lib/libz.so.6 (0x800cca000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x800ee2000)
        libthr.so.3 => /lib/libthr.so.3 (0x8010ed000)
        libc.so.7 => /lib/libc.so.7 (0x801315000)

That's from the point of view of the dynamic linker that tries to solve the dynamic library references when the executable is loaded to start a new process.

On the other hand you can query the package database:

Code: 
% pkg info -B git
git-2.18.0_2:
        libcrypto.so.9
        libintl.so.8
        libpcre.so.1
        libexpat.so.1
        libssl.so.9
        libcurl.so.4

You already see that there are some extra libraries there because the git(1) executable doesn't need all of the same libraries that some other parts of the devel/git package do.

You can also query which packages are needed by a package to fullfill those dependencies, this list might also have dependencies that are not actual shared library dependencies but are needed for other reasons:
Code: 
 % pkg info -d git
git-2.18.0_2:
        p5-CGI-4.40
        expat-2.2.5
        openssl-1.0.2p_1,1
        python27-2.7.15
        perl5-5.26.2
        p5-Error-0.17026
        curl-7.61.0_1
        pcre-8.42
        gettext-runtime-0.19.8.1_1
        cvsps-2.1_2
 
Thank you SirDice but I need a fix for one feature that is broken in the FreeBSD package which is how I ended up trying to get the third party package working.
I was hoping to contribute and integrate that fix in proper FreeBSD package but it seems a bit hard to track how fixes are managed in that project.
 
SirDice said:
It's exactly the same version. Both are 3.5.2.0.
Click to expand...

Unfortunately not which is why I was trying to troubleshoot the problem. The emby package has a fix that is not tracked with a +.0.0.0.1 which is bad but at the same time, if people are not fully familiar with the platform but make an effort at getting things available on FreeBSD, I prefer to help where/if I can.

It turns out, the package has a problem with the latest version of the libx264 (v155) since I forced my jail to update against 'latest' packages, I hit the v155 of libx264 released on the 10th of August and got the problem I faced.

Their beta package was only tested against quarterly packages. You can read the thread I originally linked to get details on the issue.
 
You must log in or register to reply here.
Back
Top