I'd like to propose moving comps to fedorahosted git.
Why? Because CVS is a pain.
I can work on fixing the automated releng tasks that use comps.
What I'd like to know is if doing this at some point over the
next few weeks (say, post-Alpha) would be a problem for people.
If it is, we can push it off until after F13 ships.
at the FESCo meeting on Tuesday, everyone except me seemed to be set on
wanting to disable the possibility to queue updates directly to stable in
Bodhi. The only reason this was not decided right there (with no outside
feedback) is that Matthew Garrett (mjg59) wants to write down a precise
policy (which may end up even more restrictive, like some arbitrary minimum
time period of testing).
He also noted that doing so "gives us an opportunity to discuss various
consequences with affected teams". But sadly, the people driving this
proposed change haven't used this opportunity to discuss this issue in a
transparent way as I would have expected (and I've been waiting for almost 3
days!), so I am doing it now. (We really need more transparency in decision
I would like to collect feedback on this issue. If you want to disable
direct stable pushes, why? Could there be a less radical solution to that
problem (e.g. a policy discouraging direct stable pushes for some specific
types of changes rather than a blanket ban)? On the other hand, if (like me)
you DON'T want that feature to go away, please provide valid use cases.
Some situations where I and others have used direct stable pushes in the
past and where I think they're really warranted and should be used:
* A new package which doesn't replace anything, and which I verified to work
fine for me. It's clearly not a completely broken package and there's no way
it can break anybody's existing setup as nobody has that package yet.
* A regression which causes big breakage at least for some people slipped
through testing for whatever reason. We urgently want the fix to get out
* A regression slipped through testing for whatever reason and the patch is
trivial. We want the fix to get out ASAP, and the risk of breakage is very
* A trivial bugfix (like a one-line diff), tested and confirmed to fix the
bug by at least one person. The risk of breakage is extremely low.
If you can think of more, please post them! But even if you just agree with
me, please reply so the other FESCo members don't think it's just me!
Is there any particular reason why online recovery is disabled in F11 pgpool-II?
Online recovery is a very important feature (fundamental, must have)
and I have to build pgpool-II just to enable it. Can't it be enabled
I maintain Multi-Master Replication Manager for MySQL in both Fedora and EPEL. With changes from 2.0.11 -> 2.1.0 there was an incompatible change in that the daemon scripts were renamed:
mmmd_agent -> mmm_agentd
mmmd_mon -> mmm_mond
Upgrades obviously break because the INIT scripts and configuration files reference the path to the files. Would a sufficient work-around be a symlink to the old path, or would that not be kosher for any reason?
Thank you for your feedback.
I never saw this anywhere before, so I'd like to ask here first, before
doing so ;)
Is it allowed to create a file ~/.mpd.conf, when building in koji and
I need to write down a password into that file, for running a testsuite.
If that file does not exist, I can't run mpich2 tests.
Here is the snipped, I intend to use:
# create ~/.mpd.conf, if it does not yet exist
if [ -e ~/.mpd.conf ]; then
# working locally, don't delete ~/.mpd.conf
echo MPD_SECRETWORD=$(pwgen -s 50 1) > ~/.mpd.conf
chmod 600 ~/.mpd.conf
# delte ~/.mpd.conf again
if [ $DONT_DEL = "FALSE" ]; then
This prefectly works with my local rpmbuild and local mock and there
won't probably be an issue with that, but is this 'the safe way' to do?
(This also use my local ~/.mpd.conf and does not owerwrite it or deletes
Thanks in advance.
for all maintainers of packages which BuildRequire qt4-devel (or qt-devel, but
the versioned virtual Provides is preferred): please, when you plan to push
updates for your packages, ALWAYS CHECK what version of Qt your package got
built against and DO NOT PUSH your update to stable before that version of Qt
goes stable! A package built against Qt 4.6 WILL NOT WORK AT ALL with Qt
4.5!!! (This is always the case, Qt is backwards- but not forwards-
Currently, buildroot overrides for Qt 4.6 are in effect (intermittently, as Qt
4.6 can and will be untagged from the buildroot on request to build updates
which need to go out soon, but we need it in the buildroot to build anything
related to KDE 4.4), so a package built now CANNOT go to stable before the big
Qt 4.6 / KDE 4.4 / SIP 4.10 update does. If you need to push an urgent update,
please ask Rex Dieter (rdieter on Freenode IRC) or another rel-eng member to
get the stuff out of the buildroot for a moment, and follow the instructions
given on IRC. If your update is not urgent, I recommend just not pushing it
out to stable before the big Qt/KDE/SIP update.
NOT FOLLOWING THOSE INSTRUCTIONS WILL LEAD TO YOUR PACKAGE BEING BROKEN IN THE
STABLE UPDATES!!! YOU HAVE BEEN WARNED!
I am sorry if I sound abrasive, but we already had at least 2 packages which
were broken due to this issue (just for 4.6, there were more such issues with
previous upgrades) and it looks like our previous devel-announce message was
not clear enough. Please double-check before you hit that "push to stable"
button! Thanks in advance.
We will look into using some less dangerous process (special build tags?) for
future Qt updates as this is just not working, but for now please be careful.
devel-announce mailing list
Talking points are key highlights of the new release. They should be
compelling, but they will not necessarily be comprehensive. There are
different types of talking points for different types of people:
general desktop users/everyone, developers, and sysadmins. For the
Fedora 13 cycle, we will also have talking points to address some of
the Spins. They are meant to provide a short, effective answer to the
question, "What cool stuff is in the latest release of Fedora?"
Each cycle, the Marketing team compiles a short list of approximately
three talking points for each of these audiences for the upcoming
release. For Fedora 13, they're found here:
If you have a talking point that you feel meets the criteria found on
the talking points SOP page at
https://fedoraproject.org/wiki/Talking_points_SOP, add it to the the
table on the F13 page with supporting information. Please make your
contributions and changes on the wiki page, so that the Marketing team
can efficiently capture and consider your input.
The Marketing team will make final adjustments to the list of talking
points at their meeting on February 23, which will be announced on the
marketing list and is open to everyone. If you are interested in
attending the meeting, the agenda, location, and time details can be
found at http://fedoraproject.org/wiki/Marketing_meetings. Following
the meeting, the finalized list of talking points will be announced,
and posted to https://fedoraproject.org/wiki/Fedora_13_Talking_Points.
We welcome you to participate in the process!
devel-announce mailing list
What's up with the login screen on rawhide these days? It's defaulting
to no longer listing available users. I can see security sensitive
reasons for this, but it's a behavior change - is it intentional?