Bug 6767

It requires a few changes.

- Supporting the dotnet target for CentOS/EPEL
- Testing with nodejs npm provided in CentOS (Fedora is v16, CentOS is v10)
- Unknown other changes as I have not tested it

The version of dotnet and nodejs not being in sync with Fedora is something I do not have the time to manage myself. If you want to make it build for EL I would gladly accept patches.

It would be faster if you just took a Fedora package and installed it on EL. The package should run, but I have not tested it.

It should all be quite doable.  I do it here: https://copr.fedorainfracloud.org/coprs/brianjmurrell/jellyfin/

Albeit using the upstream specfile, not the rpmfusion one.  Should be trivial to migrate the changes to it though.

https://github.com/rpmfusion/jellyfin/pull/1

Regarding nodejs 16: It would take updating the mock config for RPMFusion's Koji builders to enable the module. Not sure if Nicholas will agree to that.

https://pagure.io/koji/issue/2483

What do you think, Nicholas?

I've updated my PR to build on EL9 also now.  It does not need any non-default modules.

Trying PR 1 with a scratch build for el8-free (build in progress)
https://koji.rpmfusion.org/koji/taskinfo?taskID=617448

@Brian
FYI, I've modified the changelog date as it's mandatory for the changelog to be in descending order.

@Michael 
It's not a matter for me to allow or not, koji use a high level API to auto-generate mock config for each build. (not even on build target basis), so I cannot choose to enable a particular nodejs module unless I'm using this module globally for the target.

(In reply to Brian J. Murrell from comment #5)
> I've updated my PR to build on EL9 also now.  It does not need any
> non-default modules.

So running on el8 will not help
Also I'm not sure where comes from Source2->5 ? (pre-built ?)

I would prefer to use fedora npm when possible 

BuildRequires:  npm > 16 might be enought to trigger a newer module ?

(In reply to Nicolas Chauvet from comment #7)
> 
> So running on el8 will not help

Not sure I'm understanding that comment.

> Also I'm not sure where comes from Source2->5 ? (pre-built ?)

They are part of the original SRPM that was built for Fedora.
 
> I would prefer to use fedora npm when possible 

On EL8?  I'm not sure I am understanding your stated preference.  Obviously "fedora npm" can be used on Fedora but not anywhere else just like "fedora <name_of_any_package>" can't be used anywhere else.  Clearly I am just not understanding what you are saying.
 
> BuildRequires:  npm > 16 might be enought to trigger a newer module ?

Nope.  This is the mess of modularity, which I guess is why it's being dropped in F39.  A failed experiment I guess.

But it is what it is and is what we have on EL8 at the moment.

I would wonder what all might even be using the default nodejs in EL8 any more.  It's one of those things that is soooooo old that perhaps nothing would probably be using it still?

Source10 generates Source2 thru Source 5.

It looks like your scratch build pulled in the newer npm/nodejs packages and worked.

I requested EL8/EL9 branches.

https://admin.rpmfusion.org/pkgdb/package/free/jellyfin/

branches proceeded in the case you were not notified.

Thanks. I didn't get a notification. I fired off an EL8 build but it looks like Koji is busy with other tasks so it may take a while.

I really don't want to be a dick about this but did I seriously get no credit at all in either of the RPM's %changelog or git commit to the packaging for the work I contributed to this effort?

I'm also noticing you missed this portion of my PR:

https://github.com/rpmfusion/jellyfin/blob/a4fc92e12ce20f410268b714d4f88d61364f5a93/jellyfin.spec#L177-L181

Those were not just guesses on my part.  Those are from actually testing the resulting RPMs on EL8 and resolving the errors that were being caused by those settings in the unit file.

I cannot imagine why those same problems are not going to arise from the EL8 packages resulting from https://github.com/rpmfusion/jellyfin/blob/el8/jellyfin.spec.