Learn more about these different git repos.
Other Git URLs
The mono maintainer and I discussed whether to have mono build on ppc64 for F11. It was decided that that would be desirable. Building mono on a new arch requires that we build the package once using a builtin version of the C# compiler. Then we can build the package a second time using that package to provide the compiler for the arch. To do the second build we'd need to have mono-2.4-18.fc11 in the buildroot.
I don't know whether this should also be tagged for the release. The change is minor (just providing a build on ppc64) but it would allow packages using mono to build on ppc64 (if they add ppc64 to their ExclusiveArch lines). If the maintainer did that and a subsequent build of that package had to be tagged for the F11 release, the new mono (and libraries the package depended on) would have to be brought in so they are available on ppc64 as well.
If waiting for the release makes this easier, go ahead and defer this until then.
I'm ok with fixing stuff earlier rather than later, +1
tagging for buildroot.
Closing.
Just to clarify, it would seem some other stuff has now been rebuilt for mono/ppc64, but mono/ppc64 itself isn't in dist-f11(rawhide) yet.
One example, kdebindings (ticket #1573 ), was rebuilt for this, and tagged, and now has broken deps.
So, do we want the ppc64-enabled mono build in dist-f11 or not? If so, then it needs to get rebuilt/tagged, otherwise, the items with broken deps need to be rebuilt/tagged.
or perhaps I misread the mono announcement, that mono/ppc64 stuff should issued as updates, and not included in dist-f11?
The big problem is that the announcement wasn't sufficiently clear about the new mono being only in the buildroot and not in dist-f11, which left at least me and the sublib maintainer confused, and the 3 rel-eng members who +1ed the kdebindings and sublib packages (rdieter, spot, jkeating) didn't catch it either.
We can easily disable ppc64 again in kdebindings if this is desired, but the announcements need to be clearer in the future (and I'm afraid even that might not be enough: I thought my Qt 4.5 announcement was clear and still updates built against Qt 4.5 snuck into F9/F10 stable updates before Qt 4.5 itself did, causing assorted breakage).
If it wasn't clear, I'm sorry, that's my fault.
My initial feeling was that we should push it as an update after we had a few weeks of F-12 rawhide experience under our belts. That and the chaos that will come about from package dependencies needing other packages to be rebuilt and included in the release (including mono itself) is why I recommended in the announcement[1]_ only building ppc64 in the devel branch for now and hold off on changing F11 until after the release. But I'm not a mono/C# person at all so I've held off from stating that that's what everyone must do; that's really a mono-sig decision.
If people want to start rebuilding their mono using pieces with ppc64 support now, for the release, tagging mono-2.4.0-19.fc11 into the release shouldn't be a big deal. The only difference between that and what we have now is a ppc64 build. (2.4.0-18.fc11 uses a bootstrap mono to build so it is a little different in how it's created). If people want to wait, keeping the spec files with ppc64 turned off in the F11 branch is enough. Note that having the newer mono package in the repository won't be sufficient for some mono using packages because of dependencies that aren't rebuilt for ppc64.
.. _[1]: https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01409.html
At least kdebindings require nothing other than mono itself.
sublib wants mono(mscorlib) and mono(System), are those also part of mono itself?
Yes, they are.
hrm... similar to my original comment, I'd rather things get sorted out sooner rather than later, so I'm ok with tagging mono-2.4.0-19.fc11 for dist-f11 then. + 1 here.
+1, tagged (mono-2.4-19.fc11)
mono-2.4-18.fc11 should be untagged from dist-f11-override now that dist-f11 has a newer build.
mono-2.4-18.fc11 untagged
Metadata Update from @toshio: - Issue set to the milestone: Fedora 11 Final
Login to comment on this ticket.