Mono-2.4 has been built for ppc64 in F11 and devel. So people should be
able to start rebuilding packages to include ppc64 as well as the other
arches. There's a few wrinkles to watch out for:
1) Packages with dependencies will have to be built in dependency order.
For instance, a lot of packages depend on the gtk-sharp2 bindings and
those haven't been built yet.
2) Because of the imminent release of F11 we're in a freeze state. This
means getting dependencies into the Fedora11 buildroot will require
people to request tagging explicitly. This also means that if you
rebuild your package for F11 with ppc64 support and later you have to
get this package tagged into the release, all of the packages it depends
on will need to be tagged in as well (otherwise your ppc64 build will
have broken deps).
With these in mind, I'd recommend people start rebuilding their mono
packages on ppc64 in the devel branch. Keep track of the dependency
chain you encounter. Then perform your builds in the Fedora 11 branch
as updates after the release. I'm not a mono-sig member, though, so if
you guys decide something else makes sense, just be sure to come up with
a plan so we don't release with a bunch of broken dependencies.
Just a heads-up:
We hope to land a new PolicyKit version (which will turn into 1.0,
eventually) in F12 soon. The new version simplifies the API and will
require PolicyKit-using application to be ported. For more information,
have a look at the feature page:
It also has pointers to api docs and a (terse) porting guide. We already
have a collection of patches for quite a few PolicyKit-using apps, so
the transitions should be relatively painless.
We're announcing a Fedora Activity day coming up very very soon
(apologies for the short notice). This activity day is for maintainers,
QA, and release engineering folks to meet and discuss ongoing issues
with the Fedora Development Cycle and to create a proposal on how to fix
many of the issues. Note, this is not an event to decide on a solution,
it is an event to decide on a proposal, which will then be shared with
the whole community for more input and work.
The timing of this is very short, so that we may have a chance at
changing something within the Fedora 12 development cycle. Funding for
the event was only confirmed a day or two ago, hence the late notice.
If unable to attend (which most will be) but highly interested in
helping with the process, we will be attempting to setup a Fedora Talk
conference room to use throughout the event, as well as an IRC channel.
We'll try to blog the process as well and gather feedback to be used
during the event.
If you will be able to attend in person, please add your name to the
wiki page  so that we can properly plan the space needed within RHT.
While the wiki page says that the page is still under construction, the
dates are solid, the hours during the day are mostly solid, and the
location (one of the RHT buildings) is solid.
Please feel free to use the discussion page on the wiki to express your
thoughts about the event and what problems you're having with the
development cycle. Even thoughts on the initial proposal I drew up at
the bottom of the wiki page would be welcome, although I do believe that
this event will result in a proposal different from what is currently
Again we apologize for the short notice!
Fedora -- Freedom² is a feature!
Fedora-devel-announce mailing list
at the moment static system level uid/gid's are handled by setup package
and /usr/share/doc/setup-*/uidgid file. There is threshold of system
uid/gid's - it's uid/gid 100. Another way to reserve "static" uid/gid
reservation is http://fedoraproject.org/wiki/PackageUserRegistry ...
usable only for Fedora and only semi-static (as base id could be easily
As we are running out of the free uid/gid's in uidgid reservation file
(no free gid's in fact at the moment), it has to be solved somehow...
there are quite often requests for uidgid reservations as it increases
security in many cases...
What's the best way to handle that situation? One possibility is to
increase the threshold of system level id's (to 200? 300?), another is
to check current reservation and clean long-term unused reservations (I
doubt there are many such cases, so it's only temporary solution). Other
could be sharing groups (as static uid's are still available), but
that's not always good solution.
Any other idea or some prefered solution?
I'm looking for some feedback on what I've got so far for the Maintainer
== Maintainer Responsibility Policy ==
=== How long to maintain? ===
13 months from initial release.
=== Belong to the appropriate low-traffic mailing list ===
* Package maintainers will receive important announcements through
the moderated fedora-devel-announce mailing list. Maintainers
will be automatically subscribed to this list. Everyone that is
a primary maintainer of a package in Fedora is also strongly
encouraged to subscribe to the fedora-devel list, though this is
=== Manage security issues ===
* Package maintainer should handle security issues quickly, and if
they need help they should contact the Security Response Team.
=== Deal with reported bugs in a timely manner ====
* 'Nuff said.
=== Maintain stability for users ===
* Package maintainers should limit updates within a single Fedora
release to those which do not require special user action. Many
users update automatically, and if their applications stop
working from no action of their own then they will be upset.
This goes doubly for services which may break overnight.
=== Track dependency issues in a timely manner ===
* In the development tree, and to a small degree in the release
trees as well, updates to packages may cause other packages to
have broken dependencies. Maintainers will be alerted when this
happens, and should work to rebuild their packages with all due
haste. Broken dependencies may leave end user systems in a state
where no updates will be applied. In order to keep the
distribution in a reasonable state, someone will step in and
rebuild packages that have had dependency issues for some time,
but package maintainers should not rely on these rebuilds.
=== Notify others of changes that may affect their packages ===
* Some packages are depended upon by others; in this case, changes
to one package may cause issues for others. Maintainers should
be aware of the effects that changes to their packages may have,
and should alert to the fedora-devel-announce mailing list of
updates which contain ABI or API changes which may cause
dependency problems for other packages. The announcement should
occur a week before the packages update, so all maintainers
affected are notified. The announcement should include the
* Nature of the change.
* Branches (devel, F9, etc.) which will be affected by the
* Expected date of the change.
* List of packages which are affected by the change.
Generally, this is merely the list of packages which
depend directly on the package which is being updated,
and can be found with "repoquery --whatrequires package"
where "package" is the package being updated.
* If your package upgrade breaks other packages in Rawhide, you
should try to help fix the packages affected. For example, when
Python-2.5 was integrated into Rawhide, Jeremy Katz at least
fixed the important packages and queued a rebuild for all the
other packages affected.
=== Miscellaneous Items ===
* Maintainers need to maintain an upgrade path for their
* F(current-1) -> F(current) -> Rawhide
* Packages should be pushed to the Rawhide branch first. If it
builds and works fine for a few days, then it can be pushed to
F(current). If there is a good reason to push it to
F(current-1), it should be done after a few days of being in
Brian Pepple <bpepple(a)fedoraproject.org>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E