Re: [Bug 484862] GConf2-dbus : Conflicts with other packages
by Michael Schwendt
> https://bugzilla.redhat.com/show_bug.cgi?id=484862
>
>
>
>
>
> --- Comment #2 from John (J5) Palmieri <johnp(a)redhat.com> 2009-06-03 11:45:26 EDT ---
> Of course it conflicts with GConf2. It is GConf2 with a patch. Pretty much
> binary ABI compatible unless the two have diverged recently. It shouldn't be
> used beyond OLPC and even there with the fact that they are getting more memory
> and disk space they should just start using the Orbit2 dependency. It was a
> hack to reduce dependencies while still letting GNOME packages run without
> modification.
>
> DConf is the next generation DBus GConf and should be parallel installable once
> it is released (and accepted by GNOME).
Why are the relevant Obsoletes missing (commented out)?
These packages are available to package management tools.
The Fedora guidelines disallow implicit conflicts.
14 years, 11 months
evolution header: Mime-version: 1.0
by Christoph Höger
Hi folks,
I see a small problem with evolution when sending to mailinglists.
Obviously evolution puts: Mime-version: 1.0 in the header, hypermail
searches for MIME-version: and cannot find that string. So it adds it.
In turn my mail provider bounces the return message that should be sent
to me complaining about duplicate header field.
So who is wrong here? Hypermail or evolution? Is non uppercase letter
Mime-version allowed? Anyone knowing the answer?
thanks
christoph
14 years, 11 months
chkrootkit looking for new maintainer
by Michael Schwendt
I'm looking for somebody to become the "chkrootkit" package owner,
preferably not anyone who just wants to increase the list of owned
packages for some doubtful metrics.
There are no open tickets for chkrootkit in Fedora. Last upstream release
has been in Dec 2007. Upstream has been responsive, but not reliable
with regard to merging non-Fedora-specific patches.
--
Michael Schwendt <mschwendt(a)fedoraproject.org>
Fedora release 10 (Cambridge) - Linux 2.6.27.24-170.2.68.fc10.i686
loadavg: 1.00 1.23 1.50
14 years, 11 months
rawhide report: 20090603 changes
by Fedora compose checker
Compose started at Wed Jun 3 06:15:03 UTC 2009
Updated Packages:
anaconda-11.5.0.59-1.fc11
-------------------------
* Tue Jun 02 2009 Chris Lumens <clumens(a)redhat.com> - 11.5.0.59-1
- Do not show disabled repos such as rawhide during the install (#503798).
(jkeating)
Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 1
Broken deps for ppc64
----------------------------------------------------------
cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7
14 years, 11 months
Orphaning some packages (brasero, transmission and more)
by Denis Leroy
In an effort to focus more on FOSS upstream development, I am going to
be orphaning some of my Fedora packages in the near future, starting
with this first batch.
brasero (high-maintenance)
transmission
k3d (fairly complex project, and it's actually a Gnome app)
soundconverter
gpredict
grig
gstreamer-python (used by soundconverter, pitivi)
hamlib
plotutils (inactive upstream, but used by inkscape)
pstoedit (inactive upstream, but used by inkscape)
dates (inactive upstream)
ghasher (dead upstream)
gimmage (inactive upstream)
pam_keyring (should stay orphaned actually)
14 years, 11 months
Maintainer Responsibility Policy
by Brian Pepple
Hi all,
I'm looking for some feedback on what I've got so far for the Maintainer
Responsibility Policy.
http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
--
== 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
not mandatory.
* http://www.redhat.com/mailman/listinfo/fedora-devel-announce
* http://www.redhat.com/mailman/listinfo/fedora-devel-list
=== Manage security issues ===
* Package maintainer should handle security issues quickly, and if
they need help they should contact the Security Response Team.
* http://fedoraproject.org/wiki/Security/ResponseTeam
=== 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
following information:
* Nature of the change.
* Branches (devel, F9, etc.) which will be affected by the
change.
* 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
packages.
* 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
F(current).
---
Thanks,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
14 years, 11 months
uClibc orphaned
by Ivana Varekova
Hello,
I want to split uClibc from busybox package - is here a volunteer who is
willing to take care about it?
Ivana Hutarova Varekova
14 years, 11 months
Fedora Elections: Town Hall scheduling
by Matt Domsch
(resend fixing some addresses)
Now that we have our fine slate of candidates for the Board and FESCo,
I'd like to schedule two IRC Town Hall meetings for each of these groups,
over the next week.
Scheduling around 5 people (the Board candidates) is tricky. Scheduling around
all 12 FESCo candidates will probably be impossible to get everyone at
the same time. Furthermore, I want to schedule them at roughly
opposite times of the day, to give an opportunity for as many Fedora
members to join us at an hour they might be awake.
With that said, here's my proposal.
FESCo Candidate forum
Wednesday, June 3, 1400 UTC
(10am US Eastern Daylight Time, 7am US Pacific Daylight Time)
FESCo Candiate forum
Thursday, June 4, 0200 UTC
(Wed night, 10pm US Eastern Daylight Time, 7pm US Pacific Daylight Time)
Board Candidate forum
Thursday, June 4, 1400 UTC
(10am US Eastern Daylight Time, 7am US Pacific Daylight Time)
Board Candidate forum
Thursday, June 4, 0200 UTC
(Wed night, 10pm US Eastern Daylight Time, 7pm US Pacific Daylight Time)
An alternate slot for a FESCo forum, if needed, could be the latter
half of the Friday June 5 regular FESCO meeting timeslot, so starting
at 17:30UTC.
Candidates, please indicate (to me) your (un)availability for these
times.
Thanks,
Matt
CalendarMaster
14 years, 11 months
