Hi! I'm the current Pinta maintainer for Fedora. https://www.pinta-project.com https://github.com/PintaProject/Pinta/
Recently Pinta 2.0 was released and now it runs under GTK3 and .NET6 (previously it run under mono and gtk-sharp2).
I'm trying to package it but I really need some guidance because it's a new environment for me and I haven't found any resource for packaging .NET6 applications in the Fedora Wiki.
I've uploaded the current package I'm working on on copr: https://copr.fedorainfracloud.org/coprs/musuruan/pinta/
The first problem I have is that network access is required. Otherwise I'll get the following error:
* Determining projects to restore.../usr/lib64/dotnet/sdk/6.0.100/NuGet.targets(130,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json https://api.nuget.org/v3/index.json. [/builddir/build/BUILD/pinta-2.0/Pinta.sln]/usr/lib64/dotnet/sdk/6.0.100/NuGet.targets(130,5): error : Resource temporarily unavailable (api.nuget.org:443 http://api.nuget.org:443) [/builddir/build/BUILD/pinta-2.0/Pinta.sln]/usr/lib64/dotnet/sdk/6.0.100/NuGet.targets(130,5): error : Resource temporarily unavailable [/builddir/build/BUILD/pinta-2.0/Pinta.sln]Build FAILED.*
AFAIK the Fedora builders don't have internet access.
But even if I enable it, I will later get this error: *MSBUILD : error MSB1009: Project file does not exist.*
Any help is really appreciated.
Thanks,
Andrea
Hi Andrea,
Andrea Musuruane musuruan@gmail.com writes:
I'm trying to package it but I really need some guidance because it's a new environment for me and I haven't found any resource for packaging .NET6 applications in the Fedora Wiki.
Unfortunately, Fedora don't have any guidance at this point. Not many (any?) .NET packages exist in Fedora. I think if we manage to package Pinta, we should take the lessons learned and use that to start drafting the guidance/docs for other packagers.
Do you intend to package it as a copr project or are you looking to get this into Fedora proper?
The first problem I have is that network access is required.
Ugh, this is a tough one. I am not sure how to work around this. If the project needs network access to build, I am not sure how we can get it to build offline.
The standard approach that other language ecosystems take is to package all the dependencies (recursively) into Fedora until we can build the package. That might be easy if there is just one dependency for Pinta, or it may be extremely difficult if it depends (recursively) on 100 other packages.
Otherwise I'll get the following error:
/usr/lib64/dotnet/sdk/6.0.100/NuGet.targets(130,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/builddir/build/BUILD/pinta-2.0/Pinta.sln]
If the issue is just that it can not ping api.nuget.org (because that's the NuGet server location listed in a nuget.config file somewhere), what happens if you remove all references to that? Or maybe remove that and other network locations using a `<clear />`?
AFAIK the Fedora builders don't have internet access.
Yes, that's true. It's also a hard requirement for builds for "official" (non-copr) Fedora projects.
But even if I enable it, I will later get this error: MSBUILD : error MSB1009: Project file does not exist.
The command that's executed just before the error is:
/usr/bin/dotnet msbuild installer/linux/install.proj -target:Install -p:SourceDir=/root/rpmbuild/BUILD/pinta-2.0 -p:Pu blishDir=/root/rpmbuild/BUILD/pinta-2.0/publish -p:InstallPrefix=/root/rpmbuild/BUILDROOT/pinta-2.0-1.fc35.x86_64/usr -p:InstallBinDir=/root/rpmbuild/BUILDROOT/pinta-2.0-1.fc35.x86_64/usr/bin -p:InstallLibDir=/root/rpmbuild/BUILDROOT/pi nta-2.0-1.fc35.x86_64/usr/lib64 -p:InstallDataRootDir=/root/rpmbuild/BUILDROOT/pinta-2.0-1.fc35.x86_64/usr/share -p:In stallManDir=/root/rpmbuild/BUILDROOT/pinta-2.0-1.fc35.x86_64/usr/share/man -p:InstallLocaleDir=/root/rpmbuild/BUILDROO T/pinta-2.0-1.fc35.x86_64/usr/share/local
The file installer/linux/install.proj is not included in the source tarball. Looks like that's a bug that was just fixed in the 2.0.1 release https://github.com/PintaProject/Pinta/releases/tag/2.0.1:
"Fixed a missing file (installer/linux/install.proj) from the release tarball that caused the install build step to fail "
This set of changes to the spec file made the build work for me (in an environment connected to the internet):
--- SPECS/pinta.spec 2022-01-06 14:09:26.000000000 +0000 +++ /root/pinta.spec 2022-01-08 19:02:30.736041013 +0000 @@ -1,7 +1,7 @@ %global debug_package %{nil}
Name: pinta -Version: 2.0 +Version: 2.0.1 Release: 1%{?dist} Summary: An easy to use drawing and image editing program
@@ -13,7 +13,7 @@
BuildRequires: gcc BuildRequires: make -BuildRequires: dotnet +BuildRequires: dotnet-sdk-6.0 BuildRequires: gtk3-devel BuildRequires: gettext BuildRequires: intltool @@ -55,7 +55,8 @@ %{_metainfodir}/%{name}.appdata.xml %exclude %{_datadir}/appdata/%{name}.appdata.xml %{_datadir}/applications/%{name}.desktop -%{_datadir}/icons/hicolor/*/*/%{name}.* +%{_datadir}/icons/hicolor/*/*/*png +%{_datadir}/icons/hicolor/*/apps/%{name}.svg %{_datadir}/man/man1/%{name}* %{_datadir}/pixmaps/%{name}*
I am not sure that's the right way to handle the generic icons included in this application, though. I haven't gone through the icon packaging guidelines in ages.
Regards, Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
Hi Omar,
On Sat, Jan 8, 2022 at 11:45 PM Omair Majid omajid@redhat.com wrote:
Hi Andrea,
Andrea Musuruane musuruan@gmail.com writes:
I'm trying to package it but I really need some guidance because it's a new environment for me and I haven't found any resource for packaging .NET6 applications in the Fedora Wiki.
Unfortunately, Fedora don't have any guidance at this point. Not many (any?) .NET packages exist in Fedora. I think if we manage to package Pinta, we should take the lessons learned and use that to start drafting the guidance/docs for other packagers.
Do you intend to package it as a copr project or are you looking to get this into Fedora proper?
Pinta (currently v1.7.1, based on mono) is already in Fedora proper. My aim is to update it to Pinta 2 in Fedora proper for F36+.
The first problem I have is that network access is required.
Ugh, this is a tough one. I am not sure how to work around this. If the project needs network access to build, I am not sure how we can get it to build offline.
The standard approach that other language ecosystems take is to package all the dependencies (recursively) into Fedora until we can build the package. That might be easy if there is just one dependency for Pinta, or it may be extremely difficult if it depends (recursively) on 100 other packages.
These are the dependencies pinta shows in Help->About->Version Info (in bold the ones I think should be packaged):
Title,Version,Path
*AtkSharp,3.24.24.34,/usr/lib64/pinta/AtkSharp.dllCairoSharp,3.24.24.34,/usr/lib64/pinta/CairoSharp.dllClipper,6.4.2.0,/usr/lib64/pinta/Clipper.dllGdkSharp,3.24.24.34,/usr/lib64/pinta/GdkSharp.dllGioSharp,3.24.24.34,/usr/lib64/pinta/GioSharp.dllGLibSharp,3.24.24.34,/usr/lib64/pinta/GLibSharp.dllGtkSharp,3.24.24.34,/usr/lib64/pinta/GtkSharp.dll* netstandard,2.1.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/netstandard.dll *NGettext,0.6.1.0,/usr/lib64/pinta/NGettext.dll* *PangoSharp,3.24.24.34,/usr/lib64/pinta/PangoSharp.dll* Pinta,2.0.1.0,/usr/lib64/pinta/Pinta.dll Pinta.Core,2.0.1.0,/usr/lib64/pinta/Pinta.Core.dll Pinta.Docking,2.0.1.0,/usr/lib64/pinta/Pinta.Docking.dll Pinta.Effects,2.0.1.0,/usr/lib64/pinta/Pinta.Effects.dll Pinta.Gui.Widgets,2.0.1.0,/usr/lib64/pinta/Pinta.Gui.Widgets.dll Pinta.Resources,2.0.1.0,/usr/lib64/pinta/Pinta.Resources.dll Pinta.Tools,2.0.1.0,/usr/lib64/pinta/Pinta.Tools.dll System.Collections,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Collections.dll System.Collections.Specialized,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Collections.Specialized.dll System.ComponentModel,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.ComponentModel.dll System.Console,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Console.dll System.Diagnostics.DiagnosticSource,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Diagnostics.DiagnosticSource.dll System.Diagnostics.Tracing,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Diagnostics.Tracing.dll System.Linq,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Linq.dll System.Memory,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Memory.dll System.Net.Http,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Net.Http.dll System.Net.Primitives,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Net.Primitives.dll System.Net.Security,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Net.Security.dll System.ObjectModel,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.ObjectModel.dll System.Private.CoreLib,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Private.CoreLib.dll System.Private.Uri,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Private.Uri.dll System.Private.Xml,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Private.Xml.dll System.Private.Xml.Linq,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Private.Xml.Linq.dll System.Runtime,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Runtime.dll System.Runtime.InteropServices,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Runtime.InteropServices.dll System.Runtime.InteropServices.RuntimeInformation,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Runtime.InteropServices.RuntimeInformation.dll System.Security.Cryptography.X509Certificates,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Security.Cryptography.X509Certificates.dll System.Text.Encoding.Extensions,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Text.Encoding.Extensions.dll System.Text.RegularExpressions,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Text.RegularExpressions.dll System.Threading,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Threading.dll System.Threading.Thread,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Threading.Thread.dll System.Xml.XDocument,6.0.0.0,/usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0/System.Xml.XDocument.dll
Otherwise I'll get the following error:
/usr/lib64/dotnet/sdk/6.0.100/NuGet.targets(130,5): error : Unable to
load the service index for source
[/builddir/build/BUILD/pinta-2.0/Pinta.sln]
If the issue is just that it can not ping api.nuget.org (because that's the NuGet server location listed in a nuget.config file somewhere), what happens if you remove all references to that? Or maybe remove that and other network locations using a `<clear />`?
I'm not sure I follow you here.
I cannot find any nuget.config file or any file that has an occurrence of nuget in it :-/
AFAIK the Fedora builders don't have internet access.
Yes, that's true. It's also a hard requirement for builds for "official" (non-copr) Fedora projects.
But even if I enable it, I will later get this error: MSBUILD : error MSB1009: Project file does not exist.
The command that's executed just before the error is:
/usr/bin/dotnet msbuild installer/linux/install.proj -target:Install -p:SourceDir=/root/rpmbuild/BUILD/pinta-2.0 -p:Pu blishDir=/root/rpmbuild/BUILD/pinta-2.0/publish -p:InstallPrefix=/root/rpmbuild/BUILDROOT/pinta-2.0-1.fc35.x86_64/usr -p:InstallBinDir=/root/rpmbuild/BUILDROOT/pinta-2.0-1.fc35.x86_64/usr/bin -p:InstallLibDir=/root/rpmbuild/BUILDROOT/pi nta-2.0-1.fc35.x86_64/usr/lib64 -p:InstallDataRootDir=/root/rpmbuild/BUILDROOT/pinta-2.0-1.fc35.x86_64/usr/share -p:In stallManDir=/root/rpmbuild/BUILDROOT/pinta-2.0-1.fc35.x86_64/usr/share/man -p:InstallLocaleDir=/root/rpmbuild/BUILDROO T/pinta-2.0-1.fc35.x86_64/usr/share/local
The file installer/linux/install.proj is not included in the source tarball. Looks like that's a bug that was just fixed in the 2.0.1 release https://github.com/PintaProject/Pinta/releases/tag/2.0.1:
"Fixed a missing file (installer/linux/install.proj) from the release tarball that caused the install build step to fail "
I noticed that too. Now I can build pinta (if internet access is enabled): https://copr.fedorainfracloud.org/coprs/musuruan/pinta/build/3135987/
It seems that dotnet6 is not available in all Fedora supported architectures though.
Is there a way to identify these platforms?
In mono I used to have this in the SPEC file: ExclusiveArch: %mono_arches
My updated SPEC file is: https://copr-dist-git.fedorainfracloud.org/cgit/musuruan/pinta/pinta.git/tre...
I also had to add:
Requires: dotnet-runtime-6.0
I am not sure that's the right way to handle the generic icons included in this application, though. I haven't gone through the icon packaging guidelines in ages.
I have no idea about that. Specs are not really clear: https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-lat...
I have a new issue. I'm not sure if this is an upstream issue. Even though pinta is localised in different languages, only English is shown.
Thank you for your support.
BR,
Andrea
Hi Omar,
On Sun, Jan 9, 2022 at 10:56 AM Andrea Musuruane musuruan@gmail.com wrote:
Otherwise I'll get the following error:
/usr/lib64/dotnet/sdk/6.0.100/NuGet.targets(130,5): error : Unable to
load the service index for source
[/builddir/build/BUILD/pinta-2.0/Pinta.sln]
If the issue is just that it can not ping api.nuget.org (because that's the NuGet server location listed in a nuget.config file somewhere), what happens if you remove all references to that? Or maybe remove that and other network locations using a `<clear />`?
I'm not sure I follow you here.
I cannot find any nuget.config file or any file that has an occurrence of nuget in it :-/
After more digging, it seems that various csproj files have:
<ItemGroup> * <PackageReference Include="GtkSharp" Version="3.24.24.34" />* </ItemGroup>
I think this is what triggers NuGet.
The good news is that GtkSharp is the only requirements. The bad news is that GtkSharp requires other libraries: https://www.nuget.org/packages/GtkSharp/
If a GtkSharp would be provided by an RPM package, would NuGet still be called?
BR,
Andrea
The good news is that GtkSharp is the only requirements. The bad news is that GtkSharp requires other libraries: https://www.nuget.org/packages/GtkSharp/
PS Too fast. It is not the only requirements:
$ find . -type f -exec grep PackageReference {} ; <PackageReference Include="GtkSharp" Version="3.24.24.34" /> <PackageReference Include="NUnit" Version="3.13.2" /> <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.0.0" /> <PackageReference Include="NUnit3TestAdapter" Version="4.1.0" /> <PackageReference Include="GtkSharp" Version="3.24.24.34" /> <PackageReference Include="GtkSharp" Version="3.24.24.34" /> <PackageReference Include="GtkSharp" Version="3.24.24.34" /> <PackageReference Include="GtkSharp" Version="3.24.24.34" /> <PackageReference Include="GtkSharp" Version="3.24.24.34" /> <PackageReference Include="GtkSharp" Version="3.24.24.34" /> <PackageReference Include="GtkSharp" Version="3.24.24.34" /> <PackageReference Include="NGettext" Version="0.6.7" /> <PackageReference Include="SharpZipLib" Version="1.3.3" /> <PackageReference Include="ParagonClipper" Version="6.4.2" />
BR,
Andrea
Hi,
Andrea Musuruane musuruan@gmail.com writes:
After more digging, it seems that various csproj files have:
<ItemGroup> <PackageReference Include="GtkSharp" Version="3.24.24.34" /> </ItemGroup>
I think this is what triggers NuGet.
Yup, that would do it.
The good news is that GtkSharp is the only requirements. The bad news is that GtkSharp requires other libraries: https://www.nuget.org/packages/GtkSharp/
If a GtkSharp would be provided by an RPM package, would NuGet still be called?
In a default configuration, yes. But it should be trivial to configure nuget to look at the rpm packages only. All we would have to do is place a file like this in the project root:
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <clear /> <add key="local" value="/path/to/rpms/nuget-packages/" /> </packageSources> </configuration>
(And fix any existing nuget.config files in the project)
The part that's a complete unknown to me is how we would produce the nuget packages. Fedora has gtk-sharp3 packaged, and it only includes the .dll files, not the .nupkg (nuget package) files that .NET projects (including Pinta) need to build.
Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
Hi,
Andrea Musuruane musuruan@gmail.com writes:
It seems that dotnet6 is not available in all Fedora supported architectures though.
For .NET 6.0, the currently supported architectures are aarch64, s390x and x86_64. It's unlikely we will add support for additional architectures or remove support for these existing architectures for .NET 6 in Fedora.
Microsoft and .NET use a slightly different terminology to refer to these architectures; the .NET docs will refer to these as arm64, s390x and x64 respectively.
Is there a way to identify these platforms?
In mono I used to have this in the SPEC file: ExclusiveArch: %mono_arches
I am not aware of something that already exits for .NET, but that's a good idea. We should investigate this for .NET.
Thanks, Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
Hello,
In mono I used to have this in the SPEC file: ExclusiveArch: %mono_arches
I am not aware of something that already exits for .NET, but that's a good idea. We should investigate this for .NET.
For mono, those arches are defined in this file: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros.m...
# arches that mono builds on %mono_arches %{ix86} x86_64 sparc sparcv9 ia64 %{arm} aarch64 alpha s390x ppc ppc64 ppc64le
all the best, Timotheus
Hi Andrea,
As you already know, all your dependencies need to be packed. I assume when you were building for mono, the mono package had provided them for you?
Having to deal with source-building dependencies is a problem anyone faces to include a .NET application in a distro. Even when the dependencies are open-source, there is no tooling that will help you get those dependencies built. I think it's worth raising a ticket in the https://github.com/dotnet/core/ repository. I doubt it will get a high priority, but it's good to make explicit the general problem, which could be improved by better tooling. Do you want to create such a ticket? Otherwise, I can write one up.
If you run into build issues, feel free to ask them on the mailing list. You can also find us on the Libera.Chat #fedora-dotnet channel for some live interaction.
Thanks, Tom
On Tue, Jan 11, 2022 at 3:23 AM Timotheus Pokorra mailinglists@tpokorra.de wrote:
Hello,
In mono I used to have this in the SPEC file: ExclusiveArch: %mono_arches
I am not aware of something that already exits for .NET, but that's a good idea. We should investigate this for .NET.
For mono, those arches are defined in this file: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros.m...
# arches that mono builds on %mono_arches %{ix86} x86_64 sparc sparcv9 ia64 %{arm} aarch64 alpha s390x ppc ppc64 ppc64le
all the best, Timotheus _______________________________________________ DotNet SIG mailing list -- dotnet-sig@lists.fedoraproject.org To unsubscribe send an email to dotnet-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/dotnet-sig@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi!
On Tue, Jan 11, 2022 at 9:39 AM Tom Deseyn tdeseyn@redhat.com wrote:
Hi Andrea,
As you already know, all your dependencies need to be packed. I assume when you were building for mono, the mono package had provided them for you?
Dependency were already available in Fedora (both in mono and in gtk-sharp2).
Having to deal with source-building dependencies is a problem anyone faces to include a .NET application in a distro. Even when the dependencies are open-source, there is no tooling that will help you get those dependencies built. I think it's worth raising a ticket in the https://github.com/dotnet/core/ repository. I doubt it will get a high priority, but it's good to make explicit the general problem, which could be improved by better tooling. Do you want to create such a ticket? Otherwise, I can write one up.
I'm not really sure to follow you here.
If you run into build issues, feel free to ask them on the mailing list. You can also find us on the Libera.Chat #fedora-dotnet channel for some live interaction.
If I did my homework correctly pinta now needs:
GtkSharp (it is a fork of gtk-sharp3 which is available in Fedora) https://github.com/GtkSharp/GtkSharp
NGettext https://github.com/VitaliiTsilnyk/NGettext
Clipper http://www.angusj.com/delphi/clipper.php
What I noticed is that all build differently (!!!). I'm currently miles away from building them, let alone having working RPMs. The dotnet build environment seems to be so heterogeneous.
BR,
Andrea
On Sun, Jan 23, 2022 at 10:57 AM Andrea Musuruane musuruan@gmail.com wrote:
Hi!
On Tue, Jan 11, 2022 at 9:39 AM Tom Deseyn tdeseyn@redhat.com wrote:
Hi Andrea,
As you already know, all your dependencies need to be packed. I assume when you were building for mono, the mono package had provided them for you?
Dependency were already available in Fedora (both in mono and in gtk-sharp2).
Having to deal with source-building dependencies is a problem anyone faces to include a .NET application in a distro. Even when the dependencies are open-source, there is no tooling that will help you get those dependencies built. I think it's worth raising a ticket in the https://github.com/dotnet/core/ repository. I doubt it will get a high priority, but it's good to make explicit the general problem, which could be improved by better tooling. Do you want to create such a ticket? Otherwise, I can write one up.
I'm not really sure to follow you here.
See below.
If you run into build issues, feel free to ask them on the mailing list. You can also find us on the Libera.Chat #fedora-dotnet channel for some live interaction.
If I did my homework correctly pinta now needs:
GtkSharp (it is a fork of gtk-sharp3 which is available in Fedora) https://github.com/GtkSharp/GtkSharp
NGettext https://github.com/VitaliiTsilnyk/NGettext
Clipper http://www.angusj.com/delphi/clipper.php
What I noticed is that all build differently (!!!). I'm currently miles away from building them, let alone having working RPMs. The dotnet build environment seems to be so heterogeneous.
Yes, .NET tooling doesn't help you get the dependencies built. We should create a ticket about this in some https://github.com/dotnet repo to give visibility to this problem.
Tom
BR,
Andrea
dotnet-sig@lists.fedoraproject.org
-
Andrea Musuruane -
Omair Majid -
Timotheus Pokorra -
Tom Deseyn