Created attachment 1448816 [details]
build log of ppc64le

I have tried to apply the same parameters for RPM_OPT_FLAGS as was used for fixing the s390x build, but that did not make a difference.

Thanks for the report, I'm looking into it and planned to open a bug in  the morning :-)

So I'm getting no crash when building locally from the 2018-04 branch, which makes me to think there was some ppc related fix applied. How difficult it would be to update mono in rawhide to the 5.x version?

Hello Dan,
thanks for looking into fixing mono for these architectures. This is much appreciated!

Upgrading to 5.x: that would be very nice. But Claudio and myself have tried it various times. see the comments in bug 1436896.
Unfortunately Mono now uses binary files to build, that are not built by Mono, so we would need to package those. But that is not easy (or even not possible?), because they require msbuild and dotnet core to build. But I have to admit I don't know for sure.

To some degree I am waiting for .NET Core to land in Fedora (https://fedoraproject.org/wiki/SIGs/DotNet), and hope this will give support for the latest version of Mono.

Timotheus

I wonder what's missing for Mono 5.x because the Sine Nomine guys were able to build 5.12 for EPEL-7 for s390x (they are upstream for Mono on s390x), with the same package layout as our 4.8 has. I'll check with them. Their binaries are at http://download.sinenomine.net/clefos/epel7/s390x/

AFAIK bundling binaries for bootstrapping purpose is allowed.

yes, for bootstrapping that is fine.
But those additional binaries are not built from the mono package, and would need to be packaged separately.

Claudio wrote in https://bugzilla.redhat.com/show_bug.cgi?id=1436896#c82

Well, I managed to compile using mcs. But it is still necessary to keep the folder ./external/roslyn-binaries/Microsoft.Net.Compilers/Microsoft.Net.Compilers.2.6.0/* and the file ./external/binary-reference-assemblies/v4.7.1/System .Net.Http.dll from references-assemblies

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

We cannot fix Mono for Fedora 29 and rawhide due to this bug.

Can this be fixed, or should we drop support for ppc64le?

I have now added ExcludeArch: ppc64le to the Mono spec file, so that it builds in Rawhide for Fedora 30.

Since Debian managed to get Mono 5 to build according to their rules, we will probably try that for Fedora 31 too. We were too late for Fedora 30, since this affects a number of packages depending on Mono.

You should probably contact downstream packagers about this ExcludeArch, because it'll break many of them: https://apps.fedoraproject.org/koschei/affected-by/mono-core?epoch1=0&version1=4.8.0&release1=14.fc28&epoch2=0&version2=4.8.0&release2=17.fc30&collection=f30

I was just worried that Mono would fail a second mass rebuild.
I could post to the mono SIG, but it has been very quiet in the past years.

Release 30 will be branched from Rawhide tomorrow, and I will file a change proposal for Mono 5, and that will hopefully fix the situation again.

(In reply to Timotheus Pokorra from comment #10)
> I have now added ExcludeArch: ppc64le to the Mono spec file, so that it
> builds in Rawhide for Fedora 30.
> 
> Since Debian managed to get Mono 5 to build according to their rules, we
> will probably try that for Fedora 31 too. We were too late for Fedora 30,
> since this affects a number of packages depending on Mono.

It broke graphviz package and probably others who are relying on the %mono_arches macro:
$ rpm --eval %mono_arches
i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 sparc sparcv9 ia64 armv3l armv4b armv4l armv4tl armv5tl armv5tel armv5tejl armv6l armv6hl armv7l armv7hl armv7hnl aarch64 alpha s390x ppc ppc64 ppc64le

Could you update it?

Graphviz FTBFS bug 1686270.

that mono_arches is actually defined in another package: https://src.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/tree/macros.mono-srpm

For Rawhide, I hope to update to the latest Mono 5 quite soon, which should build again for ppc64, when this change is approved: https://fedoraproject.org/wiki/Changes/Mono_5

For Fedora 30, changing mono_arches to drop ppc64 is a option we should consider. Or should we dare to update Mono to version 5 in Fedora 30 after it is released? I am not sure if that is permitted at all. So dropping ppc64 Mono from Fedora 30 might be the only way.

What do you think?

(In reply to Timotheus Pokorra from comment #14)
> that mono_arches is actually defined in another package:
> https://src.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/tree/macros.
> mono-srpm
> 
> For Rawhide, I hope to update to the latest Mono 5 quite soon, which should
> build again for ppc64, when this change is approved:
> https://fedoraproject.org/wiki/Changes/Mono_5
> 
> For Fedora 30, changing mono_arches to drop ppc64 is a option we should
> consider. Or should we dare to update Mono to version 5 in Fedora 30 after
> it is released? I am not sure if that is permitted at all. So dropping ppc64
> Mono from Fedora 30 might be the only way.
> 
> What do you think?

Personally I don't know much about mono, that's why I commented here for mono maintainers to make the decision.

I am OK if you decide to drop it from the f30, in such case I would prefer changing the macro, because it will resolve the problem for everybody. I can also live without the macro change, in such case me and other maintainers will have to add workarounds to their SRPM for the f30 branch (dirty). In any case please let me know the way you decided to go. I can also create the redhat-rpm-config bug if you decided to go this way.

I like your suggestion. I filed bug 1686983 for redhat-rpm-config to drop ppc64 and ppc64le from mono_arches for Fedora 30.

this is fixed in mono-5.18.1-2.fc30 (.fc31), it's available on all arches again

mono-5.18.1-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-153a4642ad

mono-5.18.1-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-153a4642ad

mono-5.18.1-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.