I derived an ebuild for the beta version of mono (1.1.14) from the mono-1.1.13.4 ebuild. This also includes an ebuild for libgdiplus. I can compile it on my machine and run a simple testprogram. I'll attach both files to this bugreport. Maybe someone can include in the official portage tree. Haven't changed very much. Warning: The files haven't been tested seriously. If they damage your system: bad luck!
Created attachment 84120 [details] Mono-1.1.14 ebuild This is the ebuild for Mono.
Created attachment 84121 [details] Ebuild for libgdiplus This is the ebuild for libgdiplus (1.1.14)
*** Bug 130559 has been marked as a duplicate of this bug. ***
Created attachment 85097 [details] My ebuild for the latest mono beta (1.1.15) Changelog: version bump, fixed source location Tests made: ran a small testapp, compiled Monodevelop 0.10
Created attachment 85098 [details] My ebuild for the latest libgdiplus beta (1.1.15) Changelog: version bump, fixed source location
Also the 1.1.15 release is out (http://www.go-mono.com/archive/1.1.15/). This mono release fixes many bugs.
(In reply to comment #6) > Also the 1.1.15 release is out (http://www.go-mono.com/archive/1.1.15/). > > This mono release fixes many bugs. > I already attached an ebuild for this release (see above).
Ops, thank you, I need to sleep more :P
mono-1.1.15 doesn't depends on libgdiplus and shoud be emerged before! read this http://www.go-mono.com/archive/1.1.15/#contributors But libgdiplus should be obviously in dependence on mono, I gues.
Q: Could I edit my own post? Or I should type a new one? Once more...:-) Mono doesn't depend on libgdiplus! And should be emerged first! As it leads from http://www.go-mono.com/archive/1.1.15/#contributors libgdiplus could depend on mono, I didn't check it yet. Please correct your ebuilds.
(In reply to comment #10) > Mono doesn't depend on libgdiplus! But it can use it if it is installed on the system. > And should be emerged first! Afaik it doesn't matter what is installed first. I couldn't find any dependency of libgdiplus on mono. And mono just assumes that libgdiplus is installed on the system using the current ebuild. So emerging libgdiplus first is not an issue. If you don't want libgdiplus to be emerged with mono just turn off the X use flag for mono. If there is no other reason to emerge libgdiplus after mono I will leave it as it is. Nether change a running system ;)
1.1.16 is out...
(In reply to comment #12) > 1.1.16 is out... > Yes but you don't need a special ebuild to emerge it. Just renaming the current ebuild to mono-1.1.16.ebuild and creating the digest should be sufficient. Same for libgdiplus. That's why I didn't post the new ebuilds since there is no real change except of the version number. Happy testing. :)
Yeah, I know. I'm just wondering what keeps it from being in portage (last version in portage is 1.1.13.something)...
(In reply to comment #14) > Yeah, I know. I'm just wondering what keeps it from being in portage (last > version in portage is 1.1.13.something)... > I can't tell you that. Maybe noone had the time to integrate it. Since it is so easy to create a small overlay for that I don't think that is a real problem. I think it will be integrated later if a package like Beagle depends on it.
comment #14, #15: mono-1.13.x is the stable version. Typically gentoo doesn't bump packages to unstable or testing versions. No doubt mono-1.2 will go in portage when it comes out unless there is a compelling reason to put these unstable versions in.
1.1.13 is _said_ to be latest stable. From my experience with developing on mono, each new "unstable" work much better (and stable!) than 1.1.13. For anyone wishing to be up-to-date, my ebuilds for 1.1.16 follow. The ebuild went under quite excessive testing, as the company I work in uses mono .16 as our building environment. It does _not_ include the broken patch for ResourceManager (which causes proper code to fall into infinite loops) but does include our two patches for System.Data.OracleClient (also commited to mono bugzilla).
Created attachment 91346 [details] ebuild for libgdiplus 1.1.16
Created attachment 91347 [details] ebuild for mono 1.1.16
Created attachment 91348 [details, diff] Patch applied by mono-1.1.16 ebuild
Created attachment 91349 [details, diff] Patch applied by mono-1.1.16 ebuild
I get the following when trying the 1.1.16 mono ebuild: >>> Unpacking mono-1.1.16.tar.gz to /var/tmp/portage/mono-1.1.16/work * Applying mono-1.1.15-OracleTrim.diff ... [ ok ] * Applying mono-1.1.15-OracleConnNullable.diff ... [ ok ]sed: can't read /var/tmp/portage/mono-1.1.16/work/mono-1.1.16/mono/os/unix/Makefile.am: No such file or directory !!! ERROR: dev-lang/mono-1.1.16 failed. Call stack: ebuild.sh, line 1545: Called dyn_unpack ebuild.sh, line 711: Called src_unpack mono-1.1.16.ebuild, line 45: Called die !!! sed failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! This ebuild is from an overlay: '/usr/local/portage'
I've just commited 1.1.16 to the tree. This removes the bogus resource manager thing, and should be working fine. I've not included the oracle patches, as we try our hardest to only include critical fixes that haven't gotten approved by upstream/commited to SVN yet. Marking this FIXED, sorry for the delay (I only recently got the go ahead from miguel on IRC that distros should continue shipping the new 1.1.x stuff and not just the 1.1.13.x stable releases).
Install of mono-1.1.16.1 from Portage went smoothly here and seems to be playing nice with my Mono apps so far. Good work everyone, and thanks!
