Package Request: .NET Core

[agausmann]

Name: .NET Core (suggested package name: dotnet-core)

Description: ".NET Core is an open-source, general-purpose development platform maintained by Microsoft and the .NET community on GitHub. It's cross-platform (supporting Windows, macOS, and Linux) and can be used to build device, cloud, and IoT applications."

URL: https://docs.microsoft.com/en-us/dotnet/core/

Source: https://github.com/dotnet/core

Releases: https://github.com/dotnet/core/releases

[agausmann]

I'd be willing to help develop the initial package. Maybe also maintain it afterward, but I don't have much experience there.

[Anachron]

I can help you with packaging, I meant to package Emby which requires .Net anyway.

[Cogitri]

Doesn't Emby work with Mono @Anachron?

[Anachron]

Uh oh I expected Emby to use DotNet since jellyfin requires DotNet and is a fork of Emby.

[Cogitri]

I'm pretty sure it works with Mono, or at least it did like 2 months ago when I tried it out (but decided to go with Plex)

[Johnnynator]

jellyfin

jellyfin dropped support for mono, emby still supports it. But we should keep the dotnet core unrelated chatter out of this issue :)

[Anachron]

I'm trying to package dotnet right now.

Arch PKGBUILD for reference: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dotnet-runtime-1.1

Edit: I've packaged dotnet-runtime so far and now trying dotnet-sdk. Will open a PR once things get smooth.

# Template file for 'dotnet-runtime'
pkgname=dotnet-runtime
version=2.2.4
revision=1
archs="x86_64 armv7 aarch64"
wrksrc="${pkgname}-${version}"
create_wrksrc=yes
short_desc="Provides the .NET core runtime components"
maintainer="Anachron <gith@cron.world>"
license="MIT"
homepage="https://dotnet.microsoft.com"

case "${XBPS_TARGET_MACHINE}" in
	x86_64)
	_arch="x64"
	_path="853048a3-764a-4b4d-a608-c6144a84f257/99c5cb1ea145f9dc3c2bbd093c682c9b"
	distfiles="https://download.visualstudio.microsoft.com/download/pr/${_path}/${pkgname}-${version}-linux-x64.tar.gz"
	checksum="0e494df7a3936ac59c17de3b91d928bb3ab3cdd1e6734d581ad4774f551ca239"
	;;
	armv7)
	_arch="arm"
	_path="8c52648c-bedd-44b0-9442-95cd830fdada/d6ba4c50a6b2afddc4ae3d313349f3ac"
	distfiles="https://download.visualstudio.microsoft.com/download/pr/${_path}/${pkgname}-${version}-linux-arm.tar.gz"
	checksum="06cc0010e92591c350fe010feacdd6bb55294f89e97ea30eac5a46c33fd8d1f4"
	;;
	armv8)
	_arm="arm64"
	_path="9e06922d-3a96-4f0d-9eb0-94f2cf94458f/93dfe5f0ad50c0eb347e98d7f81b34ec"
	distfiles="https://download.visualstudio.microsoft.com/download/pr/${_path}/${pkgname}-${version}-linux-arm64.tar.gz"
	checksum="492de061d1e01862c2f208287c5454a19650ab2d6441554347d847656900da70"
	;;
esac

nopie=yes
nopie_files="/usr/bin/dotnet"

do_install() {
	vbin dotnet
	vlicense "${FILESDIR}/LICENSE"
}

Edit2: Here is the dotnet-sdk that I have so far (warning: doesn't build as of yet)

# Template file for 'dotnet-sdk'
pkgname=dotnet-sdk
version=2.2.203
revision=1
archs="x86_64 armv7 aarch64"
wrksrc="${pkgname}-${version}"
create_wrksrc=yes
short_desc="Provides the .NET SDK components"
maintainer="Anachron <gith@cron.world>"
license="MIT"
homepage="https://dotnet.microsoft.com"

case "${XBPS_TARGET_MACHINE}" in
	x86_64)
	_arch="x64"
	_path="647f8505-3bf0-48c5-ac0f-3839be6816d7/d0c2762ded5a1ded3c79b1e495e43b7c"
	distfiles="https://download.visualstudio.microsoft.com/download/pr/${_path}/${pkgname}-${version}-linux-x64.tar.gz"
	checksum="d1e2368b1335a6a5f496b887950ad5da3d85783ec76f74a663214989817bb497"
	;;
	armv7)
	_arch="arm"
	_path="e5573b57-df74-4b5b-8cd8-06973b66c3ac/b9ee29318ad2d87fa05adfaf74a8271c"
	distfiles="https://download.visualstudio.microsoft.com/download/pr/${_path}/${pkgname}-${version}-linux-arm.tar.gz"
	checksum="76488566b7c81f12a517274562bf5bbb77e003cd9ca568f90d9bfb2865de3242"
	;;
	armv8)
	_arm="arm64"
	_path="50979c85-1634-4c40-a4d0-4d25c9dae08d/cfa1d7e5ef765cef1d2c9127c9e14599"
	distfiles="https://download.visualstudio.microsoft.com/download/pr/${_path}/${pkgname}-${version}-linux-arm64.tar.gz"
	checksum="6f49fa85aef7f69ec04bbb4f61e4029a472d5a01ea5a4154986df27e26521879"
	;;
esac

post_extract() {
	rm dotnet
}

do_install() {
	mkdir -p usr/bin
	vcopy host usr/bin
	vlicense "${FILESDIR}/LICENSE"
}

[vikigenius]

Can we reopen this? the merge was reverted because of a whole host of issues. The major one being that it didn't seem to support libressl.

[agausmann]

I found a workaround that may lead to a more permanent fix if we can investigate it further. Installing libssl46 and setting the environment variable CLR_OPENSSL_VERSION_OVERRIDE=46 seems to work.

[0-st]

Any progress?

[toluschr]

CLR_OPENSSL_VERSION_OVERRIDE=47 works just fine.
I'd like to use this package, too.

[Luxed]

I am trying to take the work where it was stopped on PR #20147.
The first thing I did was to move the _target from "usr/lib/dotnet" to "usr/share/dotnet", which is what is recommended in the official documentation found here.

Unfortunately, as I'm just starting out with the distro and have never worked on anything similar before, I'm hitting a roadblock that I absolutely do not understand:

Error log

=> dotnet-sdk-bin-3.1.102_1: running post-install hook: 11-pkglint-elf-in-usrshare ...
=> ERROR: dotnet-sdk-bin-3.1.102_1: ELF files found in /usr/share:
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/System.Globalization.Native.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/libcoreclr.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/libclrjit.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/System.Native.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/libmscordbi.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/System.Security.Cryptography.Native.OpenSsl.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/libhostpolicy.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/libcoreclrtraceptprovider.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/libmscordaccore.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/System.Net.Security.Native.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/libdbgshim.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/System.Net.Http.Native.so
=> ERROR:    /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.2/System.IO.Compression.Native.so
=> ERROR:    /usr/share/dotnet/packs/Microsoft.NETCore.App.Host.linux-x64/3.1.2/runtimes/linux-x64/native/libnethost.so
=> ERROR:    /usr/share/dotnet/host/fxr/3.1.2/libhostfxr.so
=> ERROR: dotnet-sdk-bin-3.1.102_1: cannot continue with installation!

What does this hook do and why does it fail?

[Cogitri]

You're putting ELF files (so architecture dependant files) into /usr/share, but /usr/share is only meant for architecture independent files (e.g. icons, text files etc.). So /usr/lib does seem like the right location for the dotnet stuff.

[Luxed]

Thank you very much. I was able to get it working by putting the location in the "/etc/dotnet/install_location".
I was also able to run a simple "Hello world" console application by using CLR_OPENSSL_VERSION_OVERRIDE=47.
This is very rudimentary and cannot realistically be used.
Making sure that I can make powershell work is my next step.

[ellie-idb]

A major problem I'm (personally) running into with .NET Core:
Cannot get required symbol d2i_ASN1_type_bytes from libssl
I've double checked on my machine (with latest libssl), but...

nm -anD /usr/lib/libssl.so | grep 'ASN1'
                 U PEM_ASN1_read
                 U PEM_ASN1_read_bio
                 U PEM_ASN1_write
                 U PEM_ASN1_write_bio
000000000002e250 T SSL_use_certificate_ASN1
000000000002e4f0 T SSL_use_RSAPrivateKey_ASN1
000000000002e710 T SSL_use_PrivateKey_ASN1
000000000002ea40 T SSL_CTX_use_certificate_ASN1
000000000002ed00 T SSL_CTX_use_RSAPrivateKey_ASN1
000000000002ef50 T SSL_CTX_use_PrivateKey_ASN1

So, still looks like the same compatibility issue (as posted above) with LibreSSL remains... and the developers are intentionally going out of their way to avoid creating a compatibility layer with LibreSSL as much as possible:

On macOS the system libraries do not support AES-CCM or AES-GCM for 3rd party code, so the AesCcm and AesGcm classes use OpenSSL for support. Users on macOS need to obtain an appropriate copy of OpenSSL (libcrypto) for these types to function, and it must be in a path that the system would load a library from by default. Obtaining OpenSSL from a package manager, such as Homebrew, is recommended (but not required). The libcrypto.0.9.7.dylib and libcrypto.0.9.8.dylib libraries included in macOS are from older versions of OpenSSL, and will not be used. The libcrypto.35.dylib, libcrypto.41.dylib, and libcrypto.42.dylib are LibreSSL, and will not be used.

What a shame...

[agausmann]

Void is adding may add support for OpenSSL which will hopefully help out here. #21056

[Johnnynator]

*Might add, nothing is fully certain yet.

[aquaspy]

Okay, so osu! lazer appimage has a dependency on openssl. Is it possible use the "CLR_OPENSSL_VERSION_OVERRIDE=46" thing and make possible to osu! to open at void with libressl? Thanks!

[jcgruenhage]

Can we reopen this? the merge was reverted because of a whole host of issues. The major one being that it didn't seem to support libressl.

So, now that Void has migrated back to OpenSSL, is it worth it taking another shot at this?

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[ThePademelon]

I have .dotnet running on my machine using this script: https://dot.net/v1/dotnet-install.sh
I don't seem to be having any issues with SSL. I haven't contributed to a package repo before, but perhaps this could somehow be used?

[Nathan-MV]

https://github.com/archlinux/svntogit-community/tree/master/dotnet-core

[lissine0]

@Anachron can you please try again to package it?

[Anachron]

@lissine0 we're working on it: void-dotnet#1

[IcedQuinn]

so far the best option seems to remain just downloading the binaries and installing them somewhere.

.net is now (with the exception of CoreCLR) written in itself, bringing the same bootstrap problem most computer languages suffer from.

[lissine0]

IMO, a better option would be to run Alpine Linux in a chroot and install .net there.
Alpine Linux chroots are small. The one I have, with .net installed, is only 615 MB in size.

[IcedQuinn]

IMO, a better option would be to run Alpine Linux in a chroot and install .net there. Alpine Linux chroots are small. The one I have, with .net installed, is only 615 MB in size.

that's basically just saying the way to support software on void is to just not use void 🥴

[lissine0]

The way to support software on void is to properly package it.
Until that happens for .net, I'd rather run it in a chroot than use binaries provided by microsoft, installed using a very long shell script.
But that's my opinion

[Kratacoa]

@ahesford why was this closed?

[ahesford]

This request has been open for more than five years without moving to completion. If somebody wants to submit a pull request to take action, feel free to do so, but it's time to stop talking in circles about this.

[Anachron]

While it is true that this request is open for a long time, it is not true that nothing has happened.

There is a discussion at void-dotnet#3 which should be picked up again but is paused due to low availability of my time.

[ahesford]

I'm not arguing that nothing has happened, just that if the effort hasn't concluded in more than five years, then either this request is bogged down by endless bikeshedding, or the effort required is so monumental that it's better to do this kind of coordination in some project repository dedicated to the effort, not as comments to a new-package request.

If the effort is complete, it's time for somebody to submit a pull request. If the effort is ongoing, I suggest maintaining discussion and coordination somewhere like https://github.com/void-dotnet/void-packages. We'll be here to review a pull request when one is ready.