Introducing SourceFucker 0.1
by David Nielsen
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..
15 years
Mono SIG at FUDCon Berlin 2009
by Ismael Olea
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
15 years
Packages looking for a loving home (and a little plea on patches)
by David Nielsen
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
15 years
Can someone review some spec files for me?
by Stephen Shaw
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/
15 years
Need consensus on Mono 2.0 migration
by David Nielsen
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
15 years
