mono June 2009

mono@lists.stg.fedoraproject.org

4 participants
5 discussions

Introducing SourceFucker 0.1
by David Nielsen 15 Jun '09

15 Jun '09

You know the problem, your favorite Fedora Mono package has hardcoded references to /usr/lib, even on x86_64 which fucks things up(tm). In fact the problem is so big that many bugs filed against Mono packages has to do with missed instances of this problem. To that effect, I challenged my friend Brian, who raved about how awfu.. awesome perl is to make me a little tool to create perfect patches for this problem. Put the attached SourceFucker.pl file in ~/rpmbuild/SOURCES, then chmod +x it and everytime you download an updated tarball run ./SourceFucker.pl foo.tar.bz2. Out drops a perfect patch for you following the naming foo-libdir.patch to apply with the required top comment (which everyone seems to forget is obligatory). SourceFucker currently doesn't accept a path to the tarball but putting it in SOURCES also ensures that the patch ends up where we need it so hardly a big problem. I hope this little quick hack will be able to be extended into becoming a part of our review guidelines to ensure that we hit every instance of /lib hardcoding. This will be valid I suspect even after we rewrite the guidelines to respect managed code, just with different alterations (likely we will need to put things in datadir instead or which ever we agree upon). - David Yes, I am aware of the irony of fixing Mono packages using perl..

1 0

Mono SIG at FUDCon Berlin 2009
by Ismael Olea 15 Jun '09

15 Jun '09

Hi all: I've missed the group activity the last weeks. Anyhow I plan to full follow-up it ASAP, since I would like to contribute to the new guidelines. In this sense, how many of you will attend to Berlin? I mean: it could be the opportunity for a barcamp/hackfest of the Mono SIG working, ie, in that guidelines or other pending tasks. https://fedoraproject.org/wiki/FUDCon:Berlin_2009 I'll be there for sure, so, you could count with me. What do you think? -- A. Ismael Olea González http://olea.org/diario/ http://aduaneros.org, la ONG sin futuro. El mundo debe empezar a tener miedo a un planeta OLEA

2 1

Packages looking for a loving home (and a little plea on patches)
by David Nielsen 15 Jun '09

15 Jun '09

I've orphaned all my packages, I don't have a Fedora install with which to do package development anymore aside that my cvs access is utterly busted which I just don't have the nerves to mess with anymore. Time has come to admit that I am just not that passionate about Fedora anymore and that I at least need a long break. The cute innocent little packages in question are: webkit-sharp - C# webkit bindings. monsoon - Bittorrent client written in C# using GTK# and MonoTorrent. mono-nat - NAT handling support for Mono. banshee-mirage - The famed Mirage extension for Banshee, does spectrum analysis and makes cool playlists of similar songs for you. There is one patch for webkit-sharp sitting in bugzilla which I haven't commited yet. I would suggest that someone interested in Banshee take webkit-sharp at least as it is required for the 1.5.x series. The patch adjusts the .so version we require and is required on F11 and above for wekbit-sharp to function. This package will require paying attention to the heads up messages from the webkit maintainer (Peter Gordon - a nice guy, I promise) and if the so version is bumped then the patch needs updating. monsoon and mono-nat pretty much go hand in hand, upstream is very friendly and tends to handle bugreports well. These are a very low weight packages which shouldn't add much to the bugload of it's owner, updates are fairly rare and easy to handle. banshee-mirage is a very nice addition to the great Banshee we all know and love, it's low maintenance and upstream is very good at handling bugs. This package might be merged into banshee main at some point. Additionally there are some patches sitting in bugzilla for ndesk-dbus(-glib) from the Sugarlab guys, they need to be rebased for fuzz but they fix datastore problems they encountered in their work. It would be nice if someone could put in 10 mins of work to get those patches commited. The reportedly need this in F11 so it would be nice to let the patches simmer in rawhide for a while then unless issues arise issue the fix to our stable platforms as well. - David

2 9

Can someone review some spec files for me?
by Stephen Shaw 13 Jun '09

13 Jun '09

These are the spec files that we are using to build rpms for openSUSE. I was wondering if someone won't mind looking at them since I've never build packages for fedora. There packages require mono 2.4 so I'm hoping to be able to provide packages for fedora 11. Some of the specs don't have versions on them. That's because these files are stored in our trunk and the versions get set when we branch and tag. Thanks! Stephen http://anonsvn.mono-project.com/viewvc/trunk/uia2atk/build/specs/

4 34

Need consensus on Mono 2.0 migration
by David Nielsen 02 Jun '09

02 Jun '09

Dear list, As previously mentioned, I would love for us to start work migrating to Mono 2. This work has already been done by Ubuntu and Debian and patches are available for nearly all packages. The effect of this will be cutting the footprint of Mono apps by around 20-40% in most cases and as such presents a major advantages for our users. Jo Shields wrote a nice post to the Ubuntu devel list explaining this work: https://lists.ubuntu.com/archives/ubuntu-devel/2008-November/026872.html Debian packages along with migration patches can be found here. http://svn.debian.org/viewsvn/pkg-cli-libs/packages/ http://svn.debian.org/viewsvn/pkg-cli-apps/packages/ http://svn.debian.org/viewsvn/pkg-mono/ Now I would like to get this work into F12 which means we can start doing it now and have it finished hopefully in time for the first milestone release. This will take a concerted effort from everyone currently maintaining a mono based package and the first step has to be agreeing upon a plan of attack. I would propose the following: 1. Compile a list of packages that need patching and maintainers for these packages. 2. Every package maintainer then extracts patches for his packages from Debian and posts to the list for review. 3. Once every package on the list has patches available we commit them to cvs and announce a rebuild to fedora-devel-announce. I would like to be at 2. by June 30th, any maintainers having failed to extract a patch and get it reviewed on the list by that day should expect to have their packages manually altered by a provenpackager (this is not an excuse to sit back and let me do the work though). We should aim to be at 3. on July 15th, at which point we are up to date with pkg-mono' current progress and can interact with them for future steps. This gives us a month and a half to complete the work and leaves ample room to shake out the bugs before release. We should expect fall out, it is a major improvement and it carries risks along with it. I hope we can all pull together resources to handle bug reports stemming from this work. - David

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mono June 2009