Created attachment 2559 [details] Tweaked version of the jellyfin spec file from current Master GIT branch Since the recent release of Jellyfin 10.9.z, the upstream project has abandoned RPM packages; instead they have a link to this project. Being a long-time Fedora and EL user, I have wanted Jellyfin to work on Enterprise Linux, and in fact I have been building it myself prior to now. I am sending you a copy of the .spec file I made based on your Master GIT branch. I've made a couple of alterations where necessary to get it to build. (e.g. dotnet8 has done away with distro-specific Linux targets, moving to a generic 'linux-x64' runtime). The one thing I have not figured out how to do is specify the Modular version of npm/nodejs within the .spec file, since both EL8 and EL9 default to an older, incompatible version, but I am able to successfully build by first running: dnf -y module switch-to nodejs:20 Prior to starting the build.
I would like to also see this update on EL8. What needs to happen to get the EL builds happening with the same cadence and regularity as the Fedora builds? Is this not just a process of updating the specfile and hitting "go" and all of the supported/approved platforms build?
@Ben C Maybe your request would be better received if you pushed a PR to https://github.com/rpmfusion/jellyfin with your specfile changes?
The EL8 update has now been pushed. EL9 is only pulling in nodejs 16. I will have to find time to debug how to get v20. I have a real life and this is not my $DAYJOB. Please be patient. Thanks.
(In reply to Michael Cronenworth from comment #3) > The EL8 update has now been pushed. > > EL9 is only pulling in nodejs 16. I will have to find time to debug how to > get v20. > > I have a real life and this is not my $DAYJOB. Please be patient. Thanks. To get it to build on both EL8 and 9, I have to switch the nodejs modular stream to 20. I have no idea how to express that in a spec file. dnf -y module switch-to nodejs:20 Then run the build.
Created attachment 2562 [details] modules configuration for copr
(In reply to Ben C from comment #4) > > To get it to build on both EL8 and 9, I have to switch the nodejs modular > stream to 20. I have no idea how to express that in a spec file. I don't think you can. I guess that's one of the reasons modules failed and is now removed from Fedora. On COPR you specify modules you want installed in your build environment. I.e. https://copr.fedorainfracloud.org/coprs/brianjmurrell/jellyfin/edit_chroot/epel-8-x86_64/ Maybe that won't be visible to anyone outside of me. There is a screenshot attached that demonstrates it. I know RPMFusion is not building in COPR but perhaps whatever it is using has a similar configuration item.
I can't get into that, but the screenshot was helpful. Also, from Upstream, Jellyfin 10.9 wants Node.JS 20, which is why I've been using that (And dotNet 8) when running my builds.
EL8's ffmpeg prevents 10.9 from being used. Apologies for pushing it. The package should be dropped from EL8 unless RPMFusion wants to ship a 4.4 or newer ffmpeg. EL9's hiding of nodejs v20 behind a module stream prevents 10.9 from being built. The package build software, Koji, doesn't support enabling modules. Summary: It is not currently possible to use (EL8) or build (EL9) Jellyfin 10.9 for RHEL.
(In reply to Michael Cronenworth from comment #8) > EL8's ffmpeg prevents 10.9 from being used. Apologies for pushing it. The > package should be dropped from EL8 unless RPMFusion wants to ship a 4.4 or > newer ffmpeg. > Sorry I don't have the time to waste on updating RHEL ffmpeg.
I have untagged https://koji.rpmfusion.org/koji/buildinfo?buildID=29082
(In reply to leigh scott from comment #9) > > Sorry I don't have the time to waste on updating RHEL ffmpeg. Updating it enough to have a working Jellyfin is pretty trivial. It only needs to be >= 4.4. libvmaf needs a simple update: https://copr.fedorainfracloud.org/coprs/brianjmurrell/epel-8/build/7729441/ and then ffmpeg updates easily to 4.4.1: https://copr.fedorainfracloud.org/coprs/brianjmurrell/epel-8/build/7729647/ FWIW.(In reply to Michael Cronenworth from comment #8) > EL8's ffmpeg prevents 10.9 from being used. As noted above, updating it enough for JF is pretty trivial. > EL9's hiding of nodejs v20 behind a module stream prevents 10.9 from being > built. The package build software, Koji, doesn't support enabling modules. Once again, modularity screws us over. > Summary: It is not currently possible to use (EL8) or build (EL9) Jellyfin > 10.9 for RHEL. I guess I will just have to go back to building RPMs for it myself in COPR. It was fun here while it lasted.
(In reply to Brian J. Murrell from comment #11) > (In reply to leigh scott from comment #9) > > > > Sorry I don't have the time to waste on updating RHEL ffmpeg. > > Updating it enough to have a working Jellyfin is pretty trivial. It only > needs to be >= 4.4. Why don't you volunteer to do it instead of expecting others to do it? > > libvmaf needs a simple update: > https://copr.fedorainfracloud.org/coprs/brianjmurrell/epel-8/build/7729441/ > > and then ffmpeg updates easily to 4.4.1: > https://copr.fedorainfracloud.org/coprs/brianjmurrell/epel-8/build/7729647/ I have raised the legal flag on your repo as it breeches copr rules, your not allowed to use rpmfusion deps to build ffmpeg. > > FWIW.(In reply to Michael Cronenworth from comment #8) > > EL8's ffmpeg prevents 10.9 from being used. > > As noted above, updating it enough for JF is pretty trivial. > > > EL9's hiding of nodejs v20 behind a module stream prevents 10.9 from being > > built. The package build software, Koji, doesn't support enabling modules. > > Once again, modularity screws us over. > > > Summary: It is not currently possible to use (EL8) or build (EL9) Jellyfin > > 10.9 for RHEL. > > I guess I will just have to go back to building RPMs for it myself in COPR. > It was fun here while it lasted.
(In reply to leigh scott from comment #12) > > Why don't you volunteer to do it instead of expecting others to do it? I could have bet money on that kind of response. I was not expecting anyone to do anything. I was simply providing additional information so that an informed decision could be made. Providing a perhaps missing perspective. But why do you need to be so snarky about it? https://www.dictionary.com/browse/you-can-catch-more-flies-with-honey-than-with-vinegar So, since you extended the invitation, what is the process for somebody not in the inner-circle to volunteer to do such a thing? Do I just submit PRs and maintainers land them? Or is there more to it? Is there some documentation somewhere on how somebody volunteers to update a package or two?
(In reply to Brian J. Murrell from comment #13) > (In reply to leigh scott from comment #12) > So, since you extended the invitation, what is the process for somebody not > in the inner-circle to volunteer to do such a thing? Do I just submit PRs > and maintainers land them? Or is there more to it? Is there some > documentation somewhere on how somebody volunteers to update a package or > two? Apply for an FAS account and sign the rpmfusion CLA. https://rpmfusion.org/Contributors#Get_an_RPM_Fusion_Account Then I can sponsor you to the packager group. Here's the hard part, because you want to bump the ffmpeg abi you will need to rebuild the ffmpeg dependent packages. https://rpmfusion.org/ImportantDependencyLists#only_ffmpeg_so_bump There are abi changes so all deps need to be rebuilt. $ abipkgdiff ffmpeg-libs-4.2.9-1.el8.x86_64.rpm ffmpeg-libs-4.4.1-1.el8.x86_64.rpm ================ changes of 'libavcodec.so.58.54.100'=============== Functions changes summary: 0 Removed, 0 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 2 Removed, 5 Added function symbols not referenced by debug info Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info 2 Removed function symbols not referenced by debug info: [D] avpriv_bprint_to_extradata@@LIBAVCODEC_58 [D] avpriv_put_string@@LIBAVCODEC_58 5 Added function symbols not referenced by debug info: [A] avcodec_default_get_encode_buffer@@LIBAVCODEC_58 [A] avpriv_mpeg4audio_get_config2@@LIBAVCODEC_58 [A] avpriv_packet_list_free@@LIBAVCODEC_58 [A] avpriv_packet_list_get@@LIBAVCODEC_58 [A] avpriv_packet_list_put@@LIBAVCODEC_58 ================ end of changes of 'libavcodec.so.58.54.100'=============== ================ changes of 'libavfilter.so.7.57.100'=============== Functions changes summary: 0 Removed, 0 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 1 Removed, 0 Added function symbol not referenced by debug info Variable symbols changes summary: 1 Removed, 0 Added variable symbol not referenced by debug info 1 Removed function symbol not referenced by debug info: [D] avfilter_get_matrix@@LIBAVFILTER_7 1 Removed variable symbol not referenced by debug info: [D] avfilter_all_channel_layouts@@LIBAVFILTER_7 ================ end of changes of 'libavfilter.so.7.57.100'=============== ================ changes of 'libavformat.so.58.29.100'=============== Functions changes summary: 0 Removed, 0 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 0 Removed, 2 Added function symbols not referenced by debug info Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info 2 Added function symbols not referenced by debug info: [A] avio_print_string_array@@LIBAVFORMAT_58 [A] avio_protocol_get_class@@LIBAVFORMAT_58 ================ end of changes of 'libavformat.so.58.29.100'=============== ================ changes of 'libavutil.so.56.31.100'=============== Functions changes summary: 0 Removed, 0 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 0 Removed, 17 Added function symbols not referenced by debug info Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info 17 Added function symbols not referenced by debug info: [A] av_buffer_pool_buffer_get_opaque@@LIBAVUTIL_56 [A] av_buffer_replace@@LIBAVUTIL_56 [A] av_dovi_alloc@@LIBAVUTIL_56 [A] av_expr_count_func@@LIBAVUTIL_56 [A] av_expr_count_vars@@LIBAVUTIL_56 [A] av_film_grain_params_alloc@@LIBAVUTIL_56 [A] av_film_grain_params_create_side_data@@LIBAVUTIL_56 [A] av_gcd_q@@LIBAVUTIL_56 [A] av_hwdevice_ctx_create_derived_opts@@LIBAVUTIL_56 [A] av_image_fill_plane_sizes@@LIBAVUTIL_56 [A] av_log_once@@LIBAVUTIL_56 [A] av_opt_child_class_iterate@@LIBAVUTIL_56 [A] av_timecode_get_smpte@@LIBAVUTIL_56 [A] av_timecode_init_from_components@@LIBAVUTIL_56 [A] av_timecode_make_smpte_tc_string2@@LIBAVUTIL_56 [A] av_video_enc_params_alloc@@LIBAVUTIL_56 [A] av_video_enc_params_create_side_data@@LIBAVUTIL_56 ================ end of changes of 'libavutil.so.56.31.100'=============== Also ffmpeg-4.4.4 is the latest version in the ffmpeg 4.4 branch, it has the CVE fixes. Still interested?, it isn't a small job.
Leigh, That was a simply fantastic response. Thanks very much for it! It provides really great insight into how much more than trivial such an update is. This is something I do want to take a crack at but with my weekend nearly over and back to work tomorrow it's something I will have to plan for. I'll reach back out when I have a stretch of time to work on this. As an aside, something I'm a bit confused about though is: 2 Removed function symbols not referenced by debug info: [D] avpriv_bprint_to_extradata@@LIBAVCODEC_58 [D] avpriv_put_string@@LIBAVCODEC_58 Isn't that kind of ABI breakage supposed to necessitate a SO (i.e. major) version bump? Or am I misunderstanding breaking ABI changes and how they are supposed to affect SO versions?
(In reply to Michael Cronenworth from comment #8) ... > EL9's hiding of nodejs v20 behind a module stream prevents 10.9 from being > built. The package build software, Koji, doesn't support enabling modules. Please escalate this point with a dedicate infra ticket. We might have a mean to switch dedicated modules that are only relevant at build time.