Hello,
just to let you know: We now have Mono 4.3.2 in Rawhide. It is called Cycle 7 Alpha. In the #mono IRC I was told that it should have been named Mono 4.4, and the next Alpha release will be from the Mono 4.4 branch.
Here are the first drafts of the release notes: http://www.mono-project.com/docs/about-mono/releases/4.4.0/
One bigger change is this: "Our build system has been reconfigured to become a 4.x setup, as opposed to 4.5 only and it’s now tracking .NET 4.6.1 APIs." It seems the reference assemblies are taking a more prominent place. We are not using them for Fedora. So we can only target the latest 4.6.1 APIs. I have added symlinks for 4.0 and 4.5 to point at the latest API. That way we don't need to change the TargetFramework in the csproj files of all the packages depending on Mono in Fedora. See the changes here: http://pkgs.fedoraproject.org/cgit/rpms/mono.git/tree/mono-4.0.0-ignore-refe...
I also had quite an issue with mscorlib and other dlls not included in the rpm package. I am glad that I was still able to run koji untag-pkg as suggested in fedora-devel. So in the future, we need to build Mono packages first in copr, and then see if we can still compile other packages depending on Mono, and Mono itself with that new version.
The reason for the problems in this release is that less assemblies are in the GAC by default. Even not System.IO.dll. I don't fully understand that, but I guess it works. We just need to make sure that mono-find-provides still picks those dlls up even though they are not in the GAC. I have fixed that here: http://pkgs.fedoraproject.org/cgit/rpms/mono.git/tree/mono-4.3.2-find-provid... The Xamarin rpms have manual mention of each Provide, which we don't want in our spec file: https://github.com/mono/linux-packaging-mono/blob/centos/mono-core.spec
We are not able to build MonoDevelop 6 Alpha, because there are no tarballs released yet.
Please let me know if you find any issues with Mono in Rawhide.
Have a nice weekend, Timotheus
Hi Timotheus,
thanks a lot for sharing the information about new mono. My introduction to mono topics was due to the OpenRA project, I'm not happy with the OBS solution of upstream. Please blame me for the unbundling upstream did start as a following of my first requests.
Unfortunately, there's still ongoing discussion at upstream of OpenRA. They can not decide to leave .NET 4.0 (because of an unsupported and buggy OS developed and now definitely considered as obsolete somewhere in Redmond). Although, mono compatibility documentation clearly states .NET 4.5 as the actual standard in those days.
TBH, I do not know if there's much sense to continue with all the unbundling needed to fire OpenRA officially into Fedora. We really depend on upstream's progress in this case, so no idea what I can do to speed things up, any ideas? That seems to be more and more becoming a marketing topic instead.
~R.
Hello Raphael,
thanks a lot for sharing the information about new mono. My introduction to mono topics was due to the OpenRA project, I'm not happy with the OBS solution of upstream. Please blame me for the unbundling upstream did start as a following of my first requests.
I have read the github issues that you referenced in irc #fedora-de. https://github.com/OpenRA/OpenRA/issues/10661 Drop Windows XP and .NET 4.0 support https://github.com/OpenRA/OpenRA/issues/7140 Migrate to Open.NAT and replace Mono.Nat
Unfortunately, there's still ongoing discussion at upstream of OpenRA. They can not decide to leave .NET 4.0 (because of an unsupported and buggy OS developed and now definitely considered as obsolete somewhere in Redmond). Although, mono compatibility documentation clearly states .NET 4.5 as the actual standard in those days.
I think games are a good motivation to move technology ahead. If this helps Fedora to get more .Net technology, that is great!
But discussions about WinXP, even though it seems still quite popular in Asia, are probably leading nowhere. But again, time will change things. Microsoft is pushing Win10, even in developing countries, and who knows when people will actually make the switch. On the other hand, the existing XP machines might soon be replaced by smartphones anyway.
TBH, I do not know if there's much sense to continue with all the unbundling needed to fire OpenRA officially into Fedora. We really depend on upstream's progress in this case, so no idea what I can do to speed things up, any ideas? That seems to be more and more becoming a marketing topic instead.
I guess you have two options: * wait a couple of years, until the user base of OpenRA is not using WinXP anymore. * try to work with patches, and apply the Open.NAT patch to the Fedora package of OpenRA https://github.com/OpenRA/OpenRA/pull/10281
hope this helps, Timotheus
mono@lists.stg.fedoraproject.org
-
Raphael Groner -
Timotheus Pokorra