Mono 4 Alpha1

[Timotheus Pokorra]

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

[Timotheus Pokorra]

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

[Timotheus Pokorra]

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

[Michele Baldessari]

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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/mono