Hello,
I have just built a Mono 4.0.0 alpha1 package based on the mono 3.12.1 package from https://copr.fedoraproject.org/coprs/elsupergomez/mono/
It is available here: https://copr.fedoraproject.org/coprs/tpokorra/mono/builds/
You can see the diff of the spec file against 3.12.1 here: https://github.com/tpokorra/lbs-mono-fedora/commit/71cc758606f8bf113b7c12575...
One issue is the npgsql.dll. I am not sure if we are allowed to include compiled assemblies that are already part of the src tarball, according to https://fedoraproject.org/wiki/Packaging:Mono#Distributing_Prebuilt_Assembli... it is in the mono-4.0.0~alpha1.tar.bz2 tarball: ./external/binary-reference-assemblies/v4.0/Npgsql.dll
All the best, Timotheus
Hello Claudio, and others,
I see you have also built Mono 4 Alpha1: https://copr.fedoraproject.org/coprs/elsupergomez/mono-4/build/85185/
I hope we can share efforts to get this going, to get a newer version of Mono finally into Fedora.
One issue is the npgsql.dll. I am not sure if we are allowed to include compiled assemblies that are already part of the src tarball, according to https://fedoraproject.org/wiki/Packaging:Mono#Distributing_Prebuilt_Assembli... it is in the mono-4.0.0~alpha1.tar.bz2 tarball: ./external/binary-reference-assemblies/v4.0/Npgsql.dll
Actually, there is quite a big number of dll files in the source tarball, see the list at the end of this email.
How should we go about this? I have also sent an email to the upstream mono packagers list to ask Jo Shields who is employed by Xamarin and also is the maintainer of the Debian packages: http://lists.ximian.com/pipermail/mono-packagers-list/2015-April/000218.html
The other topic are the monolite executables. See also in the email referenced above. It seems Mono 4 requires at least Mono 3.8 to build if monolite is not used:
build/common/basic-profile-check.cs(40,30): error CS0117: `System.Version' does not contain a definition for `TryParse' /usr/lib/mono/2.0/mscorlib.dll (Location of the symbol related to previous error) build/common/basic-profile-check.cs(43,21): error CS0165: Use of unassigned local variable `version' Compilation failed: 2 error(s), 0 warnings build/profiles/basic.make:93: recipe for target 'build/deps/basic-profile-check.exe' failed make[6]: *** [build/deps/basic-profile-check.exe] Error 1 *** The compiler 'mcs' doesn't appear to be usable. *** You need Mono version 3.8 or better installed to build MCS *** Check mono README for information on how to bootstrap a Mono installation. *** The version of 'mcs' is: Mono C# compiler version 2.10.8.0. build/profiles/basic.make:60: recipe for target 'do-profile-check' failed
Another problem I see you have in your builds as well for Epel: extracting debug info from /builddir/build/BUILDROOT/mono-4.0.0-1.el7.centos.x86_64/usr/lib/mono/4.5/mscorlib.dll.so *** ERROR: No build ID note found in /builddir/build/BUILDROOT/mono-4.0.0-1.el7.centos.x86_64/usr/lib/mono/4.5/mscorlib.dll.so I have tried to add the line %global _missing_build_ids_terminate_build 0 according to https://lists.fedoraproject.org/pipermail/packaging/2011-May/007762.html but it does not make a difference. Any ideas anyone?
All the best, Timotheus
cd mono-4.0.0/external/binary-reference-assemblies/v4.0 Accessibility.dll Commons.Xml.Relaxng.dll cscompmgd.dll CustomMarshalers.dll I18N.CJK.dll I18N.dll I18N.MidEast.dll I18N.Other.dll I18N.Rare.dll I18N.West.dll IBM.Data.DB2.dll ICSharpCode.SharpZipLib.dll Microsoft.Build.dll Microsoft.Build.Engine.dll Microsoft.Build.Framework.dll Microsoft.Build.Tasks.v4.0.dll Microsoft.Build.Utilities.v4.0.dll Microsoft.CSharp.dll Microsoft.VisualBasic.dll Microsoft.VisualC.dll Microsoft.Web.Infrastructure.dll Mono.C5.dll Mono.Cairo.dll Mono.CompilerServices.SymbolWriter.dll Mono.CSharp.dll Mono.Data.Sqlite.dll Mono.Data.Tds.dll Mono.Debugger.Soft.dll monodoc.dll Mono.Http.dll Mono.Management.dll Mono.Messaging.dll Mono.Messaging.RabbitMQ.dll Mono.Posix.dll Mono.Security.dll Mono.Security.Win32.dll Mono.Simd.dll Mono.Tasklets.dll Mono.WebBrowser.dll mscorlib.dll Novell.Directory.Ldap.dll Npgsql.dll PEAPI.dll RabbitMQ.Client.dll System.ComponentModel.Composition.dll System.ComponentModel.DataAnnotations.dll System.Configuration.dll System.Configuration.Install.dll System.Core.dll System.Data.DataSetExtensions.dll System.Data.dll System.Data.Linq.dll System.Data.OracleClient.dll System.Data.Services.Client.dll System.Data.Services.dll System.Design.dll System.DirectoryServices.dll System.DirectoryServices.Protocols.dll System.dll System.Drawing.Design.dll System.Drawing.dll System.Dynamic.dll System.EnterpriseServices.dll System.IdentityModel.dll System.IdentityModel.Selectors.dll System.Json.dll System.Json.Microsoft.dll System.Management.dll System.Messaging.dll System.Net.dll System.Numerics.dll System.Runtime.Caching.dll System.Runtime.DurableInstancing.dll System.Runtime.Remoting.dll System.Runtime.Serialization.dll System.Runtime.Serialization.Formatters.Soap.dll System.Security.dll System.ServiceModel.Activation.dll System.ServiceModel.Discovery.dll System.ServiceModel.dll System.ServiceModel.Routing.dll System.ServiceModel.Web.dll System.ServiceProcess.dll System.Transactions.dll System.Web.Abstractions.dll System.Web.ApplicationServices.dll System.Web.dll System.Web.DynamicData.dll System.Web.Extensions.Design.dll System.Web.Extensions.dll System.Web.Routing.dll System.Web.Services.dll System.Windows.Forms.DataVisualization.dll System.Windows.Forms.dll System.Xaml.dll System.Xml.dll System.Xml.Linq.dll WebMatrix.Data.dll WindowsBase.dll
To report back on these questions:
Actually, there is quite a big number of dll files in the source tarball, see the list at the end of this email.
How should we go about this? I have also sent an email to the upstream mono packagers list to ask Jo Shields who is employed by Xamarin and also is the maintainer of the Debian packages: http://lists.ximian.com/pipermail/mono-packagers-list/2015-April/000218.html
Jo answered here on the mono packagers list: [1]
He told me I can drop the external binaries, they are only for supporting older .net Frameworks. So this is what I have done [2], and the resulting rpm works fine for me. find . -name "*.dll" -not -path "./mcs/class/lib/monolite/*" -print -delete find . -name "*.exe" -not -path "./mcs/class/lib/monolite/*" -print -delete
The other topic are the monolite executables.
Jo explains in [1] how they do this for Debian: they have made an exception to the rule, and use the monolite binaries included in the tarball. The question is who makes such decisions for Fedora? For an incremental upgrade, would it be possible to upgrade from 2.10 to eg. 3.2.8 in rawhide, and then to 3.12.1, and then to 4.0, without actually having the intermediate versions as part of a Fedora release?
[1]: http://lists.ximian.com/pipermail/mono-packagers-list/2015-April/000219.html [2]: https://github.com/tpokorra/lbs-mono-fedora/blob/master/mono/mono.spec#L291
On Wed, Apr 15, 2015 at 05:06:07PM +0200, Timotheus Pokorra wrote:
To report back on these questions:
Actually, there is quite a big number of dll files in the source tarball, see the list at the end of this email.
How should we go about this? I have also sent an email to the upstream mono packagers list to ask Jo Shields who is employed by Xamarin and also is the maintainer of the Debian packages: http://lists.ximian.com/pipermail/mono-packagers-list/2015-April/000218.html
Jo answered here on the mono packagers list: [1]
He told me I can drop the external binaries, they are only for supporting older .net Frameworks. So this is what I have done [2], and the resulting rpm works fine for me. find . -name "*.dll" -not -path "./mcs/class/lib/monolite/*" -print -delete find . -name "*.exe" -not -path "./mcs/class/lib/monolite/*" -print -delete
The other topic are the monolite executables.
Jo explains in [1] how they do this for Debian: they have made an exception to the rule, and use the monolite binaries included in the tarball. The question is who makes such decisions for Fedora?
You will need to bring this up to Fesco if this is a hard requirement.
For an incremental upgrade, would it be possible to upgrade from 2.10 to eg. 3.2.8 in rawhide, and then to 3.12.1, and then to 4.0, without actually having the intermediate versions as part of a Fedora release?
Probably not in a single Fedora release, as that would be a bit too invasive. If the existing mono based packages keep working, you could propose a complete upgrade to mono 4.x for F23.
So yes I think you are on the right path and if you manage to solve the buildability topic (monolite) and the mono packages keep working, there should be nothing major stopping this upgrade.
cheers, Michele
mono mailing list mono@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/mono
mono@lists.stg.fedoraproject.org
-
Michele Baldessari -
Timotheus Pokorra