mono March 2009

mono@lists.fedoraproject.org

7 participants
10 discussions

Introduction
by Huzaifa Sidhpurwala 01 Apr '09

01 Apr '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I am a new member of the fedora-mono sig, and i would like to take over the gnome-do-plugins bug review as Paul Lange does not seem to have time to further work on this. I work at Red Hat in IT and currently in fedora i do the following - - Co-editor for FWN - - Fedora Infra. sysadmin - - Maintain a few packages in fedora. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) IT Desktop Team Lead. Global Help Desk, Pune (India) Phone: +91 20 4005 7322 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFJ0fftzHDc8tpb2uURAgOGAJ9RyzzNmAUOEXhmGKzYMBnI5i6phwCcCw2d 6yNqYCVf+2LP8/6Uxm+GTuk= =S25c -----END PGP SIGNATURE-----

3 4

Presentation
by Ismael Olea 29 Mar '09

29 Mar '09

Hi all I'm a fedora packager[1] with interests in promoting Mono. I'm currently proposing Moonlight for being included, at least, in RPM Fusion.org [2]. In the preparation for v1.9 I've asked for activation of the the --with-moonlight switch compiling mono[3]. I know some people in Fedora has bad feelings with Mono. My last interest is about trolling or starting infinite mail threads. So, I would like to collect _facts_ to support Mono in Fedora. In this sense, I'll be grateful about any references you could be aware about. Thanks! [1] https://admin.fedoraproject.org/pkgdb/users/info/olea [2] https://bugzilla.rpmfusion.org/show_bug.cgi?id=436 [3] https://bugzilla.redhat.com/show_bug.cgi?id=492048 -- Ismael Olea http://olea.org/diario/

2 2

banshee-mirage update
by David Nielsen 26 Mar '09

26 Mar '09

Attached is an update to banshee-mirage to bring us up to 0.5.0 which is the latest. It has survived a mock build (rawhide x86_64) and light testing on my personal machine. Could someone please commit this and issue a build? - David

1 0

Gnome Do plugins
by Paul Lange 18 Mar '09

18 Mar '09

Hey, I created a package for Gnome Do plugins this morning. I already filed a review request (see https://bugzilla.redhat.com/show_bug.cgi?id=489014 ) but I expect some work to be left. Some on which I want to hear you opinions are below: * First I created it as a noarch package. All data are under /usr/share and it's only CIL code so I expect this to be OK. Comments? * Currently it's only one big package. In my opinion it would be good to split it into several subpackages (at least -offical and -unofficial). * When I tried all new plugins were auto-activated. I think this is a bad behavior and we should try to auto-disable them after installing. * It took some time but finally I got all BuildRequires. However I'm unsure how we should handle Requires. Every plugin needs other applications installed. Any ideas on this? Besides this it would be great if anyone have some time to look at the package. Paul

3 2

Some cleanup with David stepping away
by Toshio Kuratomi 16 Mar '09

16 Mar '09

Hi all, Since David is going to step away from the purely Fedora portion of the Mono SIG (he'll still be present upstream and will be watching bug reports for some packages, etc), I need to take care of a few administrative things. David asked that the mono-sig be left in charge of his packages and I've created a new "mono-sig" pseudo user that can own or be CC'd on packages to take care of this. Email to this user will go to this list. Before setting the permissions I would like to make sure that there's people here to take care of these packages. For this to work, we need one or more people in provenpackagers to say this sounds like a good plan and they'll jump in to fix things in these packages: * banshee-mirage * mono-nat * monsoon * webkit-sharp If that's not the case, we should orphan them and let people pick them up. It's always nice to have someone on the package who has approveacls in any case, otherwise you have to go through cvsadmins in order to make changes to the acls. The other administrative thing is that dnielsen(a)fp.o is the owner of this mailing list. We should change that as the dnielesen alias went away when David asked to have his account marked inactive. David, if you're willing to go on being the admin, I think you can just change it to a different email address. Having a few admins wouldn't hurt, though. I'm currently subscribed to this list so we can have the conversation here of what we want to do. -Toshio

1 0

Introduction
by Benjamín Valero Espinosa 10 Mar '09

10 Mar '09

Hi all, my name is Benjamin, and I have subscribed that list from [1]. I am using Fedora for about 9 months, and would like to help in testing or whatever you need. About Mono applications, I usually use Banshee, F-Spot, Gnome-Do and of course MonoDevelop. Benja [1] https://fedoraproject.org/wiki/SIGs/Mono

2 2

mono-uia
by Stephen Shaw 06 Mar '09

06 Mar '09

Hi all! I'm working on a team at novell that is working on getting UIA implemented on linux. A lot of the fun "what is mono uia?" is here [1], but the jist of it is that it makes winform apps accessible on Linux through the atk/at-spi. Our 1.0 (this month) will require mono 2.4 and gtk-sharp 2.12.8 (also this month). I was hoping to get these packages for fedora (11?). I currently have openSUSE 11.0 and 11.1 packages in the openSUSE build service [2]. Here are some links on one of my blog posts[3]. Thanks, Stephen [1] http://www.mono-project.com/Accessibility [2] [3] http://www.decriptor.com/2009/03/03/new-mono-uia-repos/

2 3

Opening salvo
by David Nielsen 06 Mar '09

06 Mar '09

Everyone, First of all thank you for all signing up to help making Mono and Mono using applications a much more enjoyable experience for Fedora users. This effort has been long underway, and I personally have very little experience with this kind of organizing. The first thing I would like to stress is that the SIG is open to everyone, regardless of skill and available time. Even if you are a user you can be a valuable asset for improving the application stack. Primarily I am thinking about sending out testing requests when major work is being done and put into the updates-testing repos, instructions will always follow. All that is required for this type of work is membership on the mailing list as well as a bugzilla account. There is on the wiki page for the SIG a sub section for "Faithful testers" I would suggest that you add your name there so that everyone might get to know each other and the maintainers might know what kind of level of testing we might expect to attain. Should you wish to get more engaged, there will always be new packages to review and other work. Learning the required skills is something we can help with if needed, there are no dumb questions, every interested person we can get is valuable and lessens the maintainship burden on everyone. Aside packaging work we will make sure that all members have access to a list of open bugs against all packages maintained by SIG members, one valuable thing would be for members to confirm bugs and using bug templates (more on this later) to get bugs in as good a shape as possible. The aim will always be to push real bugs upstream to be the least amount of work and the highest level of benefit for everyone. Now to the action points. 1) High on my list of things to do is to review and rewrite the packaging guidelines. The current ones do not encompass neither recommendations from upstream or other major distros. There isn't any information on how to obtain the information required for reviews or packaging for new packagers to learn from. I would suggest basing these new guidelines on the work Debian already has done. This does involve moving 100% managed code packages to be noarch which is a major change and will require a lot of concerted effort to announce and push correctly. Till such guidelines are in place and agreed upon, we will use the existing ones. Once such guidelines are in place I would suggest putting aside the required time to convert everything for a one time push to rawhide after which this will be our new packaging base and the old guidelines are obsoleted entirely. 2) Assessing the situation with regards to debug symbol packages, currently they are in the main package but there is a patch to let us use the same script as other packages to handle these separately. We should review this work, it will make packages smaller and bring us more in line with the rest of Fedora. 3) Reviewing Debian and Ubuntus work to obsolete Mono 1.0 for smaller packages and improved performance. 4) We need a script to monitor upstream versions and compare them to our available versions. Optimally this would file a bug against the relevant package when we are behind upstream. Typically only the most recent versions are supported so it is important that they are present on all the platforms we have supported in Fedora. 5) Improve the process for pushing the entire stack to existing stable platforms. Currently this isn't very organized and doesn't involve a recompile for all packages, it's pushed in bits instead of all at once. We need to research how to do this properly and make sure we stick to those guidelines, also we need to make this as scriptable as possible. 6) New packaging. Every new package to be brought in to the repos needs to start with an intent to package mail to the list to make sure no work is duplicated. When a bug has been filed for review this is made as a reply to that thread. Everyone capable and with time available is requested to help out with reviewing this. Both for purposes of ensuring a quality product but also so that new packagers might learn their way around the review process. If there are questions during the packaging process please feel free to contact the mailing list, we are here to help. 7) Love weeks. I would like to see us set aside every week as dedicated to loving one special application. This would involve reviewing all open bugs, making sure the version we have is up to date and that upstream requested patches have been applied. That bugs have been been pushed upstream where proper and so on. Finally this would also entail making sure that we have packages for all the plugins that program has available. I suggest the first target for a week of love would be Monodevelop. Additionally links for most of this can be found here: http://davidnielsen.wordpress.com/2009/03/05/mono-sig-full-stream-ahead/ Kind regards, David Nielsen

1 0

hi all
by Stephen Shaw 05 Mar '09

05 Mar '09

hi!

1 0

Test
by David Nielsen 04 Mar '09

04 Mar '09

The obligatory test message to confirm that the mailing list indeed does work so that business might begin. - David

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mono March 2009