mono October 2009

mono@lists.fedoraproject.org

9 participants
7 discussions

banshee crashs and mono-zeroconf update
by Paul Lange 23 Oct '09

23 Oct '09

hey, I installed F12 beta in a virtual machine and as a long time banshee use of course installed and tried banshee. It always crashed some seconds after startup with an error which seems to be connected to a bug in glibc. See https://bugzilla.redhat.com/show_bug.cgi?id=526132#c6 I noticed there's a new mono-zeroconf release out which contains a Avahi DBus backend. Maybe we can use this to workaround the bug? The updated package can be found here: http://palango.fedorapeople.org/zeroconf/ koji build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1762918 What do you think? best regards, Paul

3 4

Mono-Zeroconf and bundled NDesk.DBus
by Michel Alexandre Salim 23 Oct '09

23 Oct '09

Hi Aaron, Just noticed that Mono-Zeroconf bundles NDesk.DBus (I'm not the Fedora maintainer for it, and just noticed since due to a glibc bug, we're having to turn off all but the AvahiDBus transport). Since this, unfortunately, is not allowed (without special approval) in our packages, I'm thinking of updating our system NDesk.DBus to incorporate your patches. Do you happen to know who maintains NDesk.DBus right now? The copyright notice is unfortunately totally out of date (2006!) Also, is there any compatibility problem (beyond ABI changes) introduced by your changes? I guess we'd have to think up a new version number too.. Thanks, -- Michel Alexandre Salim

4 4

inconsistency between sources at Fedora and upstream
by Christian Krause 21 Oct '09

21 Oct '09

Hi, Sorry for the lengthy mail, but I have observed something strange in our mono packages: some of the tarballs we use in Fedora for packaging differ from upstream: During the last days I've searched a bug in f-spot where it sometimes crashed with really weird backtraces like this (Fedora 10, mono 2.2): ERROR:mini-exceptions.c:768:get_exception_catch_class: assertion failed: (class->generic_class->container_class == method_container_class) Stacktrace: at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0x00004> at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0xffffffff>2 I've found some upstream bug reports about the problem: https://bugzilla.novell.com/show_bug.cgi?id=459285 and they claimed that it got fixed in mono 2.2. Currently, F10 uses mono-core-2.2-2.fc10.i386 I've checked out the corresponding tag (mono-2_2-2_fc10) and did a "make local" which retrieved the tarball as it is in Fedora's packaging system: md5sum mono-2.2.tar.bz2 a311545a0003f1a599297d57e4e27916 mono-2.2.tar.bz2 cat sources a311545a0003f1a599297d57e4e27916 mono-2.2.tar.bz2 Then I've downloaded the official 2.2 tarball as it is linked on mono's web page: http://ftp.novell.com/pub/mono/sources/mono/mono-2.2.tar.bz2 md5sum mono-2.2.tar.bz2 da147e24d14a73d8ad52775dd4a3d165 mono-2.2.tar.bz2 The (unified) diff between both mono versions is around 500kByte and the upstream version also contains the claimed bug fix. I have seen the same problem with mono-tools: dc96a311a8fed1a3807fed92a99b6cf8 mono-tools-2.4.2.tar.bz2-upstream 49252ede8bec6e0b244f2a34712a067e mono-tools-2.4.2.tar.bz2-fedora If I read the changelogs correctly (here mono-tools latest version update: "- Bump to 2.4.2 preview 1") then we've packaged previews of official mono releases which unfortunately use the same name of the tarball as the official release. I suggest if we package previews, then we have to use the correct version/release scheme for pre-release packages: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packag… For mono-2.2 the spec file doesn't mention that a pre-release was packaged. I'm convinced that not marking the pre-releases as such is highly risky: It is not obvious when you just look at the NVR itself and so the chance is quite high that we stick to the pre-releases even in the stable Fedora releases and miss so important bug fixes from upstream. If it is OK with you, I'd like to do the following: 1. I'll just fix mono-tools (devel). 2. Regarding mono in F10: F10 is already in deep maintenance mode and so I believe we should _not_ update mono in F10 to 2.4 although the spec files are already updated. But if there is not strong reason to do it, we should do only critical bug fixes now to mono 2.2. But I would also suggest to update F10's mono package to the official 2.2 release since it would solve problems as I was looking for at the beginning and most likely it will contain also some more bug fixes from upstream. Since I'd like to get this bug fixed in F10 as fast as possible, I'd like to volunteer to do it (if somebody could approve my commit permissions ;-) ). 3. If I see it in other packages where I can commit and if there is already an official release, I'll just update them too. If I'm not sure, I'd ask for clarification on the list. Does this sound acceptable to all you? Best regards, Christian

2 3

crash course in Mono packaging the Debian way
by David Nielsen 19 Oct '09

19 Oct '09

Hi List I promised to send this out months ago.. upsie. Ubuntu has some very useful irc sessions on packaging and other concepts, in July Jo Shields (directhex) gave an introduction to Mono packaging in Debian/Ubuntu. This is a valuable read especially in learning how they work and which steps we still lack in Fedora such as properly using the GAC. As Michel and I have been debating a possible port of the work Debian has been doing slim down packages and possibly also exclude non ECMA standardized parts of the core Mono package understanding how the debian packaging is done is useful. Anyone interested in partaking in such work should definitely read this log but it is generally useful for understanding Mono so others will benefits as well. http://irclogs.ubuntu.com/2009/07/16/%23ubuntu-classroom.html I hope we can incorporate some of the things Debian does to improve the state of Mono in Fedora, there is a Mono upstream mailing list for such packaging and the debian people are very approachable for questions as well (freenode #debian-cli I believe). Kind regards, David

1 0

Tao Framework review request
by Paul Lange 08 Oct '09

08 Oct '09

Hey, I just packaged the tao framework. Would be nice if somebody could find some time to have a look at the package. review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=527986 The package itself can be found here: http://palango.fedorapeople.org/tao/ Thanks a lot! Paul

3 2

Stable RedHat mono package
by chuchiehliu＠micron.com 06 Oct '09

06 Oct '09

New to Linux and mono. Looking for a newest stable version of RedHat mono. I found a mono-1.9.1_2-installer.bin from web. Installed it and it seems work on a simple Xdevelop Forms apps I wrote. When I wrote a simple MonoDevelop 2.2 Beta 1 Forms apps, it run fine on Windows but won't run on RedHat (ver 2.6 I believe). It will fail when I do this "mono MyApps.exe" (which works for a similar Xdevelop apps). NOTE: I set the MONO_PATH=".../mono-1.9.1/lib" directory. Thus I would like to start from getting the newest stable RedHat mono package first. Thanks, Jerry The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited.

4 8

dependencies to development packages
by Christian Krause 02 Oct '09

02 Oct '09

Hi, Recently I've tried to use "rpmdev-rmdevelrpms" and I've stumbled over a strange dependency chain regarding some mono packages. Installing banshee requires eventually glib2-devel and so "rpmdev-rmdevelrpms" won't work since it can't remove glib2-devel without uninstalling banshee, too. The dependency chain is in F10: banshee -> boo -> nant -> mono-sharpcvslib -> mono-nunit-> glib2-devel and in rawhide: banshee -> mono-nunit -> glib2-devel and banshee -> nant and banshee -> boo -> nant Since in general a normal (user-)programs should not pull in any development packages for a couple of good reasons I'd like to bring this topic to your attention. ;) What do you think - does it make sense to spend some effort into trying to avoid these problems? If yes, what could be done with the problem above? I would assume since banshee needs boo for the scripting interface, that boo should not depend itself on nant... ( and in rawhide banshee should neither depend on nant nor mono-nunit, too ). Best regards, Christian

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mono October 2009