[Fedora-packaging] Re: Rawhide's Mono stack

[Paul]

Hi,

> > I know the last 3 need a rebuild as they're built using mono-addins-0.3.
> > What problems are you seeing with MD? It's working happily here.
> Bizarre, after a restart, it works too. I'm pretty sure it was not
> working this morning, right after an update.
> 
> Log files for Banshee and Tomboy attached. Any idea?

It looks likely that the big arrays code is causing some sort of problem
(it is the only difference between the x86 and x86_64 build and both
f-spot and tomboy are running fine here).

> >> It seems that the entire stack of libraries need to be recompiled --
> >> gtk-sharp2, etc., and as such we should probably coordinate the
> >> rebuilding process. If B depends on A, does a rebuild of A affect B with
> >> Mono packages? Not so sure about this; if not, it makes life easier.
> >
> > It depends (sorry). Mono itself doesn't typically need anything for a
> > rebuild. However, if something is built against mono-tools or
> > mono-addins (such as MD and f-spot), then these will break. I've not
> > noticed anything big break with gtk-sharp2 or gnome-sharp.
> 
> Ah, ok. but if, say, gtk-sharp2 needs to be rebuilt, would a Mono
> package that depends on it need to be rebuilt, if the version number
> stays the same? i.e. do we have a C situation, or a C++ situation
> where the ABI of DLLs might change with compiler version.

It shouldn't, unless something big gets changed (it's the same as if you
update gtk itself, unless the ABI is changed then recompiling is not
always required). The only thing which may cause a problem is if
gtk-sharp2 (say) is looking for something in particular from Mono and
it's not there. Then gtk-sharp2 will need a rebuild, but if it's only a
rebuild anything reliant shouldn't be broken.

> >> Another item: as I proposed in -devel recently, we could probably get
> >> more Infrastructure support.
> >> - - our own disttag, similar to the one for the gcc44 test rebuilds earlier
> >> - - that would probably require our own mailing list, to coordinate
> >> matters like this
> >
> > This would make a lot of sense and would also make the version numbering
> > a hell of a lot simpler
> >
> With the guideline in mind, how about using 0.x.DATEsvnREV until the
> package is stable, and then switching to normal revision numbers?

I'm following the way it's done for mono-cecil-flowanalysis and xmms
which has it REVsvnDATE. If I swap to DATEsvnREV, won't that cause a
problem or would I just up x by 1 and that solves any issues?

> I'm still unable to run banshee and tomboy -- after the rebuild. The
> exceptions thrown do not really make any sense. I'm attaching them,
> hopefully someone can make some sense out of them. Anyone else
> experiencing problems?

I'm going to build and commit mono, mono-tools, monodevelop, f-spot and
tomboy tonight (UK time - should hit rawhide tomorrow) and remove the
big arrays. If the problem continues, let me know.

TTFN

Paul
-- 
Sie können mich aufreizen und wirklich heiß machen!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20090210/4323420a/attachment.sig>