Heads up - mono 2.6.7 on it's way
by Paul F. Johnson
Hi,
At the end of next week, Novell will be releasing the new version of
mono (2.6.7).
I'm currently building it for rawhide (well, the release candidate). The
new version fixes lots of bugs and is generally a damned sight faster
than previous versions.
Also being built : libgdiplus, xsp, mod_mono and mono-tools
Mono package maintainers do not need to recompile other apps against it.
2.6.7 is the last (unless there is a 2.6.7.1) of the 2.6 branch. From
2.8, support for .NET 1.1 will be dropped. If anyone still has an app
which uses the 1.1 framework, it'll die in the 2.8 branching. I suggest
either contacting upstream for .NET 2.0 framework patches, fixing it
yourself or retiring it from rawhide.
Failing that, it may be possible to create a -compat package, but I
don't know the mileage in that or even if it's worth it.
TTFN
Paul
--
Biggles was quietly reading his favourite book when Algy burst through
the door. Distracted for a moment, Biggles surveyed what had happened
and turned a page. "Algy old man" he said, clearing his throat, "use the
handle next time..." - Taken from "Biggles combs his Hair"
13 years, 8 months
mono-4-preview subpackage conditionalized
by Dan Horák
Hi all,
I had to conditionalize the mono-4-preview subpackage as it isn't
buildable on s390(x). A traceback thrown during the build. An upstream
bug report with all relevant details will follow.
Dan
13 years, 9 months
Introduce myself, and bring some ideas
by Claudio Rodrigo
Hi all, I am Claudio Rodrigo.
I use mono for quite some time and several of my favorite software runs with
mono.
I am interested to help in mono-based software package. I was watching the
packages monodevelop-java monodevelop-database monodevelop-python in
backtrack, and learning how to make rpm with them for inclusion in the
repositories. I am also trying to pack pdfmod, hyena, and tangerine.
I have little experience packaging, but I have to learn.
One idea I have is suggesting as a feature for Fedora 14, the creation of a
category of development for mono packages.
If anyone wants to help me I am open to learn to collaborate. If anyone
speaks Spanish is very welcome to talk, because it is my natural language.
Greetings to everyone.
Claudio Pereyra Rodrigo Diaz
--
That´s Life... Vive ahora como si fueras a morir mañana...
13 years, 9 months
abrt bug reports for mono-core
by Christian Krause
Hello Mono maintainers,
there is quite a large number of automatic abrt bug reports for the
mono-core package. Unfortunately, we are way too few people to deal with
all of them and the actual content of these bug reports quite often not
sufficient to solve the problems.
Please can you have a look at the following proposal and tell me your
opinion?
Due to the automatic abrt bug reporting mechanism there are many bug
reports for the core mono package coming in. There are three major
problems with this:
1. There are more issues than the few maintainers can deal with. Since
it is quite easy to report a bug with abrt, there are many reports where
the reporter does not care too much (most time there is no description
how to reproduce the issues). If there would be fewer and more specific
bug reports, there would be a higher probability that these problems get
at least some attention.
2. Lots of the reported issues are caused by problems in the original
package (e.g. DllNotFoundExceptions etc.) and are not caused by bugs of
the mono runtime itself. This means, that all of these issues are not
assigned to the correct project and so the NVR of the executed mono
programs are not known. Additionally usually the output of the mono
process is important, because the backtrace of the managed code is not
included in the bug reports (e.g.
https://bugzilla.redhat.com/attachment.cgi?id=424805).
3. To make 2. even worse, I assume that the algorithm which checks for
duplicates in the backtraces does not work 100% correct for mono
backtraces and so issues of many different applications are migrated
into one bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=558857
https://bugzilla.redhat.com/show_bug.cgi?id=605220
This alone makes it very hard to track these issues.
Sure, 2. and 3. can be solved by enhancing abrt. However it would not
help with the first item.
So I see two options here:
a) leave everything as it is
Fewer problems will be solved because it is hard to decide which
problems are really important and the maintainers are distracted because
of 2. and 3.. In reality, most of the automatic bug reports will be
ignored although the abrt tool gave the user the hope that somebody will
care about it.
b) turn off abrt for mono for rawhide, F-14, F-13, F-12
The maintainers can concentrate on problems for reporters which really
care about issues and so take the burden to file specific bug reports.
Nevertheless we should work together with the abrt developers to enhance
the automatic bug reports with respect to the issues described above.
The ultimate goal should be to re-enable the support when the backtraces
and duplicate detection are better (and there are probably again some
more mono maintainers).
I would certainly vote for b).
So what do you think? ;-)
Best regards,
Christian
13 years, 9 months