-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear Fedora Mono developers,
(ps if you are not in http://fedoraproject.org/wiki/SIGs/Mono, I get your name from the changelog of relevant *-sharp packages; please consider adding your name)
The current Mono stack in post-alpha Rawhide is rather broken -- as of today, on my machine (x86_64) none of these packages work: - - monodevelop - - banshee - - tomboy - - f-spot
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.
If there are dependencies, then one way I could suggest is that we all commit updated specs, and then someone (Paul?) could do a chain build of all the packages.
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
Thoughts? Suggestions?
Thanks in advance,
- -- miʃel salim • http://hircus.jaiku.com/ IUCS • msalim@cs.indiana.edu Fedora • salimma@fedoraproject.org MacPorts • hircus@macports.org
Hi,
The current Mono stack in post-alpha Rawhide is rather broken -- as of today, on my machine (x86_64) none of these packages work:
- monodevelop
- banshee
- tomboy
- f-spot
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.
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.
AFAIK, the only one with a really nasty circular dependency problem is nant with mono-cecil-flowanalysis. The move to the 2.4 pre-releases should not be causing any significant problems.
If there are dependencies, then one way I could suggest is that we all commit updated specs, and then someone (Paul?) could do a chain build of all the packages.
I'm fine for that :-)
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
TTFN
Paul
On Mon, Feb 9, 2009 at 5:18 PM, Paul paul@all-the-johnsons.co.uk wrote:
Hi,
The current Mono stack in post-alpha Rawhide is rather broken -- as of today, on my machine (x86_64) none of these packages work:
- monodevelop
- banshee
- tomboy
- f-spot
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 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.
If there are dependencies, then one way I could suggest is that we all commit updated specs, and then someone (Paul?) could do a chain build of all the packages.
I'm fine for that :-)
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 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?
Thanks,
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
On Tue, 2009-02-10 at 23:06 +0000, Paul wrote:
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?
Just always bump x, that's what it is there for. Not every scm has a linear increasing revision number.
packaging@lists.fedoraproject.org