Bug 2170536 - Packaging macro and/or runtime ID update in upstream list
Summary: Packaging macro and/or runtime ID update in upstream list
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dotnet6.0
Version: 39
Hardware: aarch64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Omair Majid
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 2238840
TreeView+ depends on / blocked
 
Reported: 2023-02-16 16:17 UTC by Michael Cronenworth
Modified: 2024-04-11 14:55 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-04-11 14:55:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Michael Cronenworth 2023-02-16 16:17:42 UTC
Description of problem:
When building on an aarch64 host and attempting to produce a aarch64 binary the resulting apphost binary is actually x86_64.

As far as I can tell this has always been like this on Fedora builds.

Jellyfin build:
https://koji.rpmfusion.org/koji/buildinfo?buildID=24691


Version-Release number of selected component (if applicable):
dotnet-sdk-6.0                 aarch64 6.0.113-1.fc38              build  72 M
aspnetcore-runtime-6.0         aarch64 6.0.13-1.fc38               build 7.2 M
aspnetcore-targeting-pack-6.0  aarch64 6.0.13-1.fc38               build 1.4 M
dotnet-apphost-pack-6.0        aarch64 6.0.13-1.fc38               build 3.6 M
dotnet-host                    aarch64 7.0.2-1.fc38                build 196 k
dotnet-hostfxr-6.0             aarch64 6.0.13-1.fc38               build 155 k
dotnet-runtime-6.0             aarch64 6.0.13-1.fc38               build  21 M
dotnet-targeting-pack-6.0      aarch64 6.0.13-1.fc38               build 2.2 M
dotnet-templates-6.0           aarch64 6.0.113-1.fc38              build 2.5 M



Is it possible the runtime identifier on Fedora for ARM is not correctly being set?

Please also check dotnet7.0 and if there is an update please publish it for Fedora 36 and higher. Thanks.

Comment 1 Michael Cronenworth 2023-02-16 16:32:13 UTC
This may be a packaging issue on my side. I'm setting '--runtime fedora.%{fedora}-x64' when building Jellyfin. Should aarch64 be "--runtime fedora.%{fedora}-arm64" ?

Comment 2 Omair Majid 2023-02-16 16:47:45 UTC
(In reply to Michael Cronenworth from comment #1)
> This may be a packaging issue on my side. I'm setting '--runtime
> fedora.%{fedora}-x64' when building Jellyfin. Should aarch64 be "--runtime
> fedora.%{fedora}-arm64" ?

Yes, that sounds right.

I wonder if we should work on an RPM macro to compute x64/arm64/whatever correctly for any given Fedora architecture.

> Please also check dotnet7.0 and if there is an update please publish it for Fedora 36 and higher.

I kicked off the builds last night. Updates are now in progress:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-d8382f7f24
https://bodhi.fedoraproject.org/updates/FEDORA-2023-8e27c6bfea

Comment 3 Michael Cronenworth 2023-02-16 17:49:34 UTC
(In reply to Omair Majid from comment #2)
> I wonder if we should work on an RPM macro to compute x64/arm64/whatever
> correctly for any given Fedora architecture.

Yes, please.

> I kicked off the builds last night. Updates are now in progress:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-d8382f7f24
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-8e27c6bfea

Thanks.

I was taking a look at the upstream runtime ID list and it looks like it stops at F38. Is it time to add F39, F40, etc.?

https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.NETCore.Platforms/src/runtime.json

Comment 4 Omair Majid 2023-02-16 18:10:38 UTC
> I was taking a look at the upstream runtime ID list and it looks like it stops at F38. Is it time to add F39, F40, etc.?

The upstream runtime id list is generally treated as a compatibility matrix. It's effectively append-only and has been growing non-stop, even impacting .NET startup time for certain scenarios. That makes .NET upstream hesitant about adding future/unreleased versions. They only consider future versions when we can show them "this is now in use/active development". That kind of rules out adding F40 right now.

Since Fedora 39 branched recently and container images are now available that claim to be Fedora 39, I was able to put out PRs for that:

- main: https://github.com/dotnet/runtime/pull/82185
- 7.0: https://github.com/dotnet/runtime/pull/82208
- 6.0: https://github.com/dotnet/runtime/pull/82210

There are also longer term plans to move way from needing to maintain that RID list: https://github.com/dotnet/designs/pull/260

Comment 5 Michael Cronenworth 2023-02-16 18:48:24 UTC
OK, thanks for the update.

Comment 6 Fedora Release Engineering 2023-08-16 07:07:09 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

Comment 8 Michael Cronenworth 2024-03-12 13:54:54 UTC
Thanks, Omair, for your continued work on this.

Comment 9 Omair Majid 2024-04-02 18:46:24 UTC
See also https://src.fedoraproject.org/rpms/dotnet8.0/blob/c5f452d31d85d11de19732837609d4b1470bda16/f/macros.dotnet (which is currently in updates-testing for all Fedora releases).

With that we have 3 macros now:

- %dotnet_arches contains a list of architectures supported by .NET
- %dotnet_runtime_arch is the current runtime architecture name (currently one of arm64, ppc64le, s390x or x64)
- %dotnet_runtime_id is the full non-portable runtime identifier (eg, fedora.41-x64). If you want the portable runtime identifier, you can use `linux-%{dotnet_runtime_arch}`.

Comment 10 Michael Cronenworth 2024-04-03 13:17:44 UTC
Thanks, Omair!

Comment 11 Omair Majid 2024-04-11 14:55:24 UTC
The changes for `%dotnet_runtime_arch` and `%dotnet_runtime_id` are live for all Fedora versions.

`%dotnet_arches` is live in Fedora 40 and later. Let me know if you (or anyone else) wants this in Fedora 38 or 39.


Note You need to log in before you can comment on or make changes to this bug.