mono July 2010

mono@lists.fedoraproject.org

5 participants
4 discussions

Heads up - mono 2.6.7 on it's way
by Paul F. Johnson 24 Aug '10

24 Aug '10

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"

2 8

mono-4-preview subpackage conditionalized
by Dan Horák 15 Jul '10

15 Jul '10

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

1 0

Introduce myself, and bring some ideas
by Claudio Rodrigo 04 Jul '10

04 Jul '10

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...

4 3

abrt bug reports for mono-core
by Christian Krause 02 Jul '10

02 Jul '10

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

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mono July 2010