Introduction
by Huzaifa Sidhpurwala
-----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-----
15 years
banshee-mirage update
by David Nielsen
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
15 years, 1 month
Gnome Do plugins
by Paul Lange
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
15 years, 1 month
Some cleanup with David stepping away
by Toshio Kuratomi
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
15 years, 1 month
Introduction
by Benjamín Valero Espinosa
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
15 years, 1 month
mono-uia
by Stephen Shaw
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/
15 years, 1 month
Opening salvo
by David Nielsen
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
15 years, 1 month
Test
by David Nielsen
The obligatory test message to confirm that the mailing list indeed does
work so that business might begin.
- David
15 years, 1 month