jellyfin vue manual installation on freeBSD

[iPleyGit]

Would there be an option to install a freebsd jail the jellyfin vue web client?

https://github.com/orgs/jellyfin/packages/container/package/jellyfin-vue

[Thefrank]

FreeBSD does not have native docker support if you want to use the docker image you will need to use bhyve and a linux distro. Additionally, jellyfin-vue does not build on freebsd because one of the hundreds of dependences it has fails to build, in this case its mozjpeg. There might be other things stopping it to but it failed out at first error:

  ✖ Error: Command failed: /bin/sh -c ./configure --enable-static --disable-shared --disable-dependency-tracking --with-jpeg8  --prefix="/root/jellyfin-vue/node_modules/mozjpeg/vendor" --bindir="/root/jellyfin-vue/node_modules/mozjpeg/vendor" --libdir="/root/jellyfin-vue/node_modules/mozjpeg/vendor"
./configure: PKG_PROG_PKG_CONFIG: not found
./configure: 13779: Syntax error: word unexpected (expecting ")")

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... no
checking for cc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking whether cc understands -c and -o together... yes
checking dependency style of cc... none
checking how to run the C preprocessor... cc -E
checking whether we are using the GNU C compiler... (cached) yes
checking whether cc accepts -g... (cached) yes
checking for cc option to accept ISO C89... (cached) none needed
checking whether cc understands -c and -o together... (cached) yes
checking dependency style of cc... (cached) none
checking for ar... ar
checking the archiver (ar) interface... ar
checking dependency style of cc... none
checking the archiver (ar) interface... (cached) ar
checking build system type... amd64-unknown-freebsd12.2
checking host system type... amd64-unknown-freebsd12.2
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by cc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
checking the name lister (/usr/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 393216
checking how to convert amd64-unknown-freebsd12.2 file names to amd64-unknown-freebsd12.2 format... func_convert_file_noop
checking how to convert amd64-unknown-freebsd12.2 file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm output from cc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if cc supports -fno-rtti -fno-exceptions... yes
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.o... (cached) yes
checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... freebsd12.2 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking whether ln -s works... yes
checking size of size_t... 8
checking whether compiler supports pointers to undefined structures... yes
checking whether __SUNPRO_C is declared... no
checking for pow in -lm... yes

    at /root/jellyfin-vue/node_modules/bin-build/node_modules/execa/index.js:231:11
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Promise.all (index 0)
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"freebsd","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.4 (node_modules/vue-native-websocket/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.4: wanted {"os":"darwin","arch":"any"} (current: {"os":"freebsd","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"freebsd","arch":"x64"})

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! mozjpeg@7.0.0 postinstall: `node lib/install.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the mozjpeg@7.0.0 postinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

[Thefrank]

more confusingly. the latest version of mozjpg builds fine from ports and is the latest version found on GH too so I have no idea why it would be failing from npm

edit: im an idiot. build system didnt have pkgconf installed and that module needed it to build

[Thefrank]

long version:

gonna be honest: I am not quite sure what to do with this. it connects into an already existing jellyfin server as a front end. It also does not produce anything exportable.

I assume the docker container is for people that want to use it without having to compile a bunch of node modules and manually setup and environment for it to work in. The docker package will also use a factor larger in not only size(MB) but resources consumed (RAM) than just running it off a jail/chroot/something else lightweight/etc

unless it compiles to something I can export I really don't have much I can do with it. I generally hate using managed code. npm install reported over 400(!) packages with issues, 3 of which were critical security ones! docker containers are static (with few exceptions) but jails or something flexible like it can easily update if vulnerable code needs to be replaced. A static package would require a level of work somewhere between making a new docker (easy, there is an API for that) and making a new jail export (can have issues, not end-user friendly).

short-ish version:

I will leave this ticket open for a bit while I try a figure out a good, safe, user-friendly solution but I am leaning towards not creating for FreeBSD for it.

If you want to run it now the general idea is rather simple:

• clone repo
• npm install
• npm run prod
• when its done: ctrl+z then bg as I am not quite sure how npm can daemonize something

a good number of the modules it uses don't have natively built binaries so they had to be built from source, this can take a very long time but you really only have to it when modules are updated.

[iPleyGit]

Thanks for the effort, a shame that it cannot be achieved in a simple way, even so I will be aware in case something is discovered in the future

another option as they already have it mounted on a test server, but they have https protocol, is to know how to configure in freebsd so that jellyfin works with https

I have tried it with a domain in OVH and I have not been able to get it to work.

[scineram]

There is a typo in Freenas install guide. It wants to fetch 10.7.6 from 10.7.2 directory.

[Thefrank]

@scineram thanks for the heads up on that!

ps. @Sicer I am closing this topic for now as vue is still pretty experimental