Bugs that block unmasking mono on amd64 should block this bug and bugs waiting for mono on amd64 should depend on this bug.
oops, sorry for the bugspam
The one dep is in the wrong spot it seems. Moved to the blocks section.
Ok, having tracked down the one bug that was the source of so much worry for me, I'm recommending libgdiplus-1.1.13 and mono-1.1.13.1 for stabalization on amd64 (and x86, but i'll deal with those folks separately). Feel free to harass me with questions, etc.
afaik beagle needs to be bumped before doing this so i'm adding Daniel so he can see the progress.
Ok, had forgotten that mono-1.1.13.x was in package.mask to await some Mono.Posix fixes in applications. No apps marked stable have issues with it, and the only app in ~arch that still has issues is beagle. Waiting on that before removing the package.mask entry.
I can't really bump beagle because I do not currently have access to an arch where the mono USE flag is available. I posted a proposed ebuild to bug 116654. If someone on x86 could test and commit it, then I guess we could mark 1.13.1 stable, enable the mono USE flag, and put beagle in ~amd64 all in one go?
Ok Daniel i'll do that with you. Yesterday i tested 0.2.1 on amd64 and is fine now i'm going to test on my x86 and commit.
Remember to handle bug 121286 as well
I'm going to suggest that we not try such acrobatic, 'syncronize our watches' type stuff for doing this. I suggest: 1) Bump beagle, same ~arch keywords present. 2) Let things settle, and get the mono-1.1.13* package.mask removed. 3) Give the usual ammount of testing, throw ATs at it on amd64, etc. 4) Mark it (and libgdiplus of course) stable. 5) Do sh*tloads more testing of the use.mask remove (it affects all sorts of things, like dbus, etc, etc). 6) Remove the use.mask entry, probably in some new profile post 2006.0 release? . . . 6.5? 8?) Add ~amd64 to beagle. Also of note, you folks could also stabalize 1.1.12 right now if you wanted, without waiting on the Mono.Posix fixes, but I'd not really suggest that, as it may just complicate the Mono.Posix stuff later.
(In reply to comment #9) > I'm going to suggest that we not try such acrobatic, 'syncronize our watches' > type stuff for doing this. > > I suggest: > > 1) Bump beagle, same ~arch keywords present. > 2) Let things settle, and get the mono-1.1.13* package.mask removed. > 3) Give the usual ammount of testing, throw ATs at it on amd64, etc. > 4) Mark it (and libgdiplus of course) stable. > 5) Do sh*tloads more testing of the use.mask remove (it affects all sorts of > things, like dbus, etc, etc). > 6) Remove the use.mask entry, probably in some new profile post 2006.0 release? > . > . > . > 6.5? 8?) Add ~amd64 to beagle. 1.5) Test every app that deps on mono for general stability and usability.
kingtaco: It should be noted that the *only* reason that mono-1.1.13* was in package.mask in the first place was because of API changes in Mono.Posix. The general stability is in no question from a "remove the package.mask" perspective. The mono-1.1.x series has already been proven to be stable, and most issues have been resolved in point releases, (1.1.13.1, etc). I think that the full testing of all mono using apps should be the focus at stage 2.5, as 1) of course it is a requirement before marking stable and 2) it will bring wider testing by ~arch users to the 1.1.13.x stuff.
(In reply to comment #11) > kingtaco: It should be noted that the *only* reason that mono-1.1.13* was in > package.mask in the first place was because of API changes in Mono.Posix. gotcha. Then the only thing we need to look at is anything that uses Mono.Postfix(avoiding API mismatches)
beagle is ready now...
What's the status here now? All dependency are already fixed.
The status is... the testing tree is tested and fixed now we are testing the stable and we found a few broken packages that we are trying to fix. Of course you can also test the last version of mono against the stable, help us fixing bugs or report any problems with it.
ok mono is stable on amd64. The use flag has been unmasked. Feel free to test more packages and open bugs for requests to keywords. Thanks all.
