Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build on EL8 #1

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Conversation

brianjmurrell
Copy link

Changes required to build on EL8 with it's nodejs:16 module.

Changes required to build on EL8 with it's nodejs:16 module.
@kwizart
Copy link
Member

kwizart commented Nov 6, 2023

Is there a macro for dotnet to fetch the appropriate vendor ? Because right now we are using alma to build for rhel and compatible, but we might change to build with rhel (or rocky) in the future, centos stream been considered as a different distro.

Also I'm not sure we can fetch a non-default module in our buildsys. So It's probably better to introduce EL9 support first, than EL8 at this time.

@kwizart
Copy link
Member

kwizart commented Nov 6, 2023

Please also consider to submit a ticket to bugzilla.rpmfusion.org so the maintainer get notified.

@brianjmurrell
Copy link
Author

Is there a macro for dotnet to fetch the appropriate vendor ?

I have no idea.

Because right now we are using alma to build for rhel and compatible, but we might change to build with rhel (or rocky) in the future, centos stream been considered as a different distro.

Those should all support the %{rhel} macro. Specifically Alma would be breaking it's ABI/API promise if it didn't and Rocky is continuing to promise bug-for-bug compatibilty as will whoever else uses OpenELA's sources. I think we are pretty safe here.

Also I'm not sure we can fetch a non-default module in our buildsys.

Is this reference to the nodejs:16 module reference. FWIW, COPR support this, as of course does mock.

So It's probably better to introduce EL9 support first, than EL8 at this time.

I'm not sure why such an ordering would be necessary. I'm not sure what bearing one has on the other. Indeed, I'd expect the EL9 build to look much more like Fedora and so really not contribute much if anything to an EL8 build.

Please also consider to submit a ticket to bugzilla.rpmfusion.org so the maintainer get notified.

Already done a few months ago: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6767.

ProtectHostname and ProtectKernelLogs
If Privateusers is set to true on EL8, jellyfin-server fails to start up with:

[2023-11-10 10:36:02.635 -05:00] [INF] [1] Main: Kestrel listening on "Any IP4 Address"
[2023-11-10 10:36:03.805 -05:00] [ERR] [1] Main: Kestrel failed to start! This is most likely due to an invalid address or port bind - correct your bind configuration in network.xml and try again.
[2023-11-10 10:36:03.805 -05:00] [FTL] [1] Main: Error while starting server.
System.Net.Sockets.SocketException (13): Permission denied
   at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportOptions.CreateDefaultBoundListenSocket(EndPoint endpoint)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.TransportManager.BindAsync(EndPoint endPoint, ConnectionDelegate connectionDelegate, EndpointConfig endpointConfig, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.<>c__DisplayClass30_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.EndpointsStrategy.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(IEnumerable`1 listenOptions, AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Hosting.WebHost.StartAsync(CancellationToken cancellationToken)
   at Jellyfin.Server.Program.StartApp(StartupOptions options)
[2023-11-10 10:36:03.821 -05:00] [INF] [1] Main: Running query planner optimizations in the database... This might take a while
[2023-11-10 10:36:04.010 -05:00] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing "CoreAppHost"
[2023-11-10 10:36:04.012 -05:00] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing "EmbyTV"
[2023-11-10 10:36:04.019 -05:00] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing "SchedulesDirect"
[2023-11-10 10:36:04.019 -05:00] [INF] [1] Emby.Server.Implementations.ApplicationHost: Disposing "MusicBrainzAlbumProvider"
[2023-11-10 10:36:04.028 -05:00] [INF] [2] Main: Received a SIGTERM signal, shutting down
@brianjmurrell
Copy link
Author

That should be the final commit necessary for EL8. I have the 10.8.12 build running on my machine on EL8 now.

I don't have an EL9 system to test on however. Clearly it builds. Cannot be sure it doesn't need the same treatment as EL8 in the latter two commits. Not likely as it's closer to Fedora than EL8 at this point.

@jmontleon
Copy link

Is there a macro for dotnet to fetch the appropriate vendor ? Because right now we are using alma to build for rhel and compatible, but we might change to build with rhel (or rocky) in the future, centos stream been considered as a different distro.

I helped a couple people get jellyfin working on ppc64le. One was building / using jellyfin on AlmaLinux 8 and the macros / rids were a problem.

I didn't find a specific macro to tell them apart and I found it to be kind of a pain to differentiate them, but this worked for me when trying a build in containers for each.
https://copr-dist-git.fedorainfracloud.org/cgit/jmontleon/jellyfin-ppc64le/jellyfin.git/tree/jellyfin.spec#n3

Basically, alma and rocky also set the centos and rhel rpm macros, and likewise centos sets the rhel macro. There is also a mishmash of dotnet rids available between them almalinux has only rhel.x-$arch, rocky has a rocky.x-$arch (and I think also rhel and centos), centos only centos.x-$arch, rhel rhel.x-$arch ...

As an aside the only major gotchas for ppc64le are dotnet availability solved by dotnet 7+ (and also for s390x) there being no libSkiaShap.so for the arch in the package downloaded which can be solved by building it and dropping it in place. s390x being big endian I also had to write a questionable patch to make some probably incomplete changes to get skia to build, but that's not necessary for ppc64le.
https://www.nuget.org/packages/SkiaSharp.NativeAssets.Linux/2.88.7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants