Bug 1752940 - build of mono for EPEL 8
Summary: build of mono for EPEL 8
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: mono
Version: epel8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Timotheus Pokorra
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1792998
TreeView+ depends on / blocked
 
Reported: 2019-09-17 15:52 UTC by Breno
Modified: 2020-05-13 05:12 UTC (History)
11 users (show)

Fixed In Version: mono-6.6.0-8.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-13 05:12:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Breno 2019-09-17 15:52:20 UTC
Hi,

I would like to ask a build of mono for EPEL 8.

Would you mind requesting the branches and build them?

Building it from src.fedoraproject.org, I only had to do a small change, prevented /usr/lib/rpm/mono-find-provides of being installed from mono-devel, once it is also provided by rpm-build.

Thank you very much.


- Breno

Comment 1 Timotheus Pokorra 2019-09-18 04:32:48 UTC
I guess we should upgrade to Mono 5.18 at the same time. It seems that is for long term support, since Debian Buster has that Mono version.

Comment 2 Timotheus Pokorra 2019-10-21 04:40:33 UTC
Quick Update: On the mailinglist, I announced the plan of providing Mono 5.18 in Epel8:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/TYMH72KDBSV5Z4QAYK6BCUZTXJDGAGYX/

Neil Gompa suggested to go for Mono 6.4 immediately.
I liked that idea, and tried it for Fedora Rawhide.
Unfortunately, I still have issues building Mono 6.4: https://copr.fedorainfracloud.org/coprs/tpokorra/mono-6.4/builds/

My current work on the spec file and patches is here:
https://github.com/tpokorra/mono-6.x-fedora/tree/master/mono-6.4

Or do people think it is better to have Mono 5.18 in Epel than nothing?

Comment 3 Timotheus Pokorra 2019-10-24 06:15:30 UTC
the build error from bootstrap can be seen in the build log:

if test -w /builddir/build/BUILD/mono-6.4.0.198/mcs; then :; else chmod -R +w /builddir/build/BUILD/mono-6.4.0.198/mcs; fi
cd /builddir/build/BUILD/mono-6.4.0.198/mcs && make --no-print-directory -s NO_DIR_CHECK=1 PROFILES='net_4_x xbuild_12 xbuild_14             ' CC='gcc' all-profiles
make[6]: mcs: Command not found
make[6]: *** [build/profiles/build.make:134: build/deps/basic-profile-check.exe] Error 127
*** The runtime 'mono' doesn't appear to be usable.
*** Trying the 'monolite-linux/62731146-81CF-4D61-826D-9A8DDED14432' directory.
error CS2001: Source file `build/common/basic-profile-check.cs' could not be found
Compilation failed: 1 error(s), 0 warnings
make[8]: *** [build/profiles/build.make:134: build/deps/basic-profile-check.exe] Error 1
*** The contents of your 'monolite-linux/62731146-81CF-4D61-826D-9A8DDED14432' directory may be out-of-date
*** You may want to try 'make get-monolite-latest'
make[8]: *** [build/profiles/build.make:117: do-profile-check-monolite] Error 1
make[7]: *** [build/profiles/build.make:93: do-profile-check] Error 2
make[6]: *** [build/profiles/build.make:129: do-profile-check-monolite] Error 2
make[5]: *** [build/profiles/build.make:93: do-profile-check] Error 2
make[4]: *** [Makefile:57: profile-do--build--all] Error 2
make[3]: *** [Makefile:53: profiles-do--all] Error 2
make[2]: *** [Makefile:657: all-mcs] Error 2
make[2]: Leaving directory '/builddir/build/BUILD/mono-6.4.0.198/runtime'
make[1]: *** [Makefile:590: all-recursive] Error 1
make[1]: Leaving directory '/builddir/build/BUILD/mono-6.4.0.198'
make: *** [Makefile:520: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.lz4o6s (%build)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.lz4o6s (%build)
Child return code was: 1
EXCEPTION: [Error()]
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/mockbuild/trace_decorator.py", line 95, in trace
    result = func(*args, **kw)
  File "/usr/lib/python3.7/site-packages/mockbuild/util.py", line 745, in do_with_status
    raise exception.Error("Command failed: \n # %s\n%s" % (command, output), child.returncode)
mockbuild.exception.Error: Command failed: 
 # /usr/bin/systemd-nspawn -q -M 89a319d46ce640e1ba06f2644a36f17d -D /var/lib/mock/1078358-fedora-31-x86_64-1571891134.666679/root -a --capability=cap_ipc_lock --bind=/tmp/mock-resolv.p0zagh3m:/etc/resolv.conf --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$  --setenv=LANG=en_US.UTF-8 -u mockbuild bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/mono.spec


It seems, the monolite included in the tarball is not sufficient. But we don't want to download the monolite from the web, because the build can only be from the tarball.

I tried to copy files around, that are missing or in the wrong place, but did not succeed yet.

Comment 4 Timotheus Pokorra 2019-12-27 17:15:04 UTC
It is now working in my copr: https://copr.fedorainfracloud.org/coprs/tpokorra/mono-6.6/builds/

I am now trying to get libgdiplus for epel8, and then will build mono 6.6 for epel8.

Comment 5 Timotheus Pokorra 2020-01-20 22:12:46 UTC
We have Mono 6.6 in Rawhide now.

Unfortunately, mdoc is gone, when building with mcs.
https://github.com/mono/mono/blob/2019-08/mcs/tools/mdoc/Makefile#L49

That means quite a number of packages need fixing that depend on mdoc... eg. mono-tools and newtonsoft-json

Comment 6 Timotheus Pokorra 2020-04-25 12:51:32 UTC
mdoc has been fixed in F32.

I have now built Mono for Epel8 with bootstrap enabled.
Now trying to build without bootstrap.

I get this error:

DEBUG util.py:600:  Error: Transaction test error:
DEBUG util.py:600:    file /usr/lib/rpm/mono-find-provides from install of mono-devel-6.6.0-6.el8.x86_64 conflicts with file from package rpm-build-4.14.2-26.el8_1.x86_64
DEBUG util.py:600:    file /usr/lib/rpm/mono-find-requires from install of mono-devel-6.6.0-6.el8.x86_64 conflicts with file from package rpm-build-4.14.2-26.el8_1.x86_64

So this needs to be fixed. Do we need to put the scripts into another directory?

Comment 7 Timotheus Pokorra 2020-04-25 12:52:31 UTC
Or we drop those files from the epel builds, because they are not needed here, because rpm-build still provides them

Comment 8 Fedora Update System 2020-04-25 21:06:49 UTC
FEDORA-EPEL-2020-21d2ce425f has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-21d2ce425f

Comment 9 Fedora Update System 2020-04-26 05:26:35 UTC
FEDORA-EPEL-2020-21d2ce425f has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-21d2ce425f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Peter Oliver 2020-04-26 11:08:32 UTC
(In reply to Timotheus Pokorra from comment #6)

> I get this error:
> 
> DEBUG util.py:600:  Error: Transaction test error:
> DEBUG util.py:600:    file /usr/lib/rpm/mono-find-provides from install of
> mono-devel-6.6.0-6.el8.x86_64 conflicts with file from package
> rpm-build-4.14.2-26.el8_1.x86_64
> DEBUG util.py:600:    file /usr/lib/rpm/mono-find-requires from install of
> mono-devel-6.6.0-6.el8.x86_64 conflicts with file from package
> rpm-build-4.14.2-26.el8_1.x86_64
> 
> So this needs to be fixed. Do we need to put the scripts into another
> directory?

We had the dependency generators removed from version 4.15 of RPM, because the Mono-provided ones are better (https://github.com/rpm-software-management/rpm/issues/673).  However, until RHEL catches up (presumably not until RHEL 9), I think we have to use RPM's outdated versions and live with the incorrect dependencies that result from that.

Comment 11 Breno 2020-04-27 13:20:32 UTC
A big thanks for building it,  Timotheus!

Comment 12 Fedora Update System 2020-05-13 05:12:32 UTC
FEDORA-EPEL-2020-21d2ce425f has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.