mod_python upstream has been inactive for five years, since Graham
Dumpleton went to work on mod_wsgi. IMO it is long past time to retire
mod_python in Fedora. But the following packages still depend on it:
Source : glump-0.9.11-10.fc17.src.rpm
Source : koji-1.6.0-3.fc17.src.rpm
Source : viewvc-1.1.13-1.fc17.src.rpm
Source : yawn-0-0.3.20120227svn561.fc18.src.rpm
I haven't checked whether these are simply to convert over to WSGI or
not. Does anybody want to maintain mod_python? If not, I'm going to
As requested during the FESCo meeting, I am going to try to summarize
some of the issues inherent in the way that Bodhi updates currently
First, I'll try to explain the goals and constraints:
1) The stable 'fedora-updates' yum repository should NEVER exist in a
state where any package has dependency issues. In other words, it should
never be possible for an update to be pushed to stable that breaks
cleanly updating any other package.
2) Updates must be possible and (ideally) timely. This is probably
3) Packages pushed to the stable 'fedora-updates' yum repository should
(ideally) not introduce regressions in packages that depend on them.
4) New features in "superpackages" such as Firefox, GNOME or FreeIPA
that have many and varied dependencies may require new features in
packages they depend on in order to enhance or fix the superpackage.
In the trivial example, a package (let's say libtalloc) needs to make an
update to fix a bug. This package requires nothing new from its
dependencies and is a self-contained fix. For this example, it is simple
to just build libtalloc in koji and then create a Bodhi update and pass
it through "updates-testing", get karma and *poof* off to
Now let's extend the example. Suppose that we have another package
libtevent that has libtalloc as a dependency. Libtevent's maintainer
wants to add a new feature to libtevent, but the patch from upstream
depends on the bug in libtalloc having been fixed in order for the new
feature to work properly. In this situation, the maintainer of libtevent
would build libtevent with an explicit Requires: libtalloc >= <version>
in the specfile (possibly pulling libtalloc into the BuildRoot overrides
if necessary) and then test it locally to see that it works.
So now we have our first updates dependency issue. If we submit
libtevent as its own update, it is possible that it will achieve its
karma requirement before libtalloc does. It would then be pushed to the
"fedora-updates" repository and then introduce a dependency issue in the
stable repository (because users trying to update libtevent would be
unable to update libtalloc without enabling the updates-testing
The current recommended approach is to bundle the two updates into a
single one carrying multiple packages. The first problem with this is
that you must have commit privilege on all packages that you are
bundling into an update. If you do not, then you need to track down a
provenpackager to do it for you.
Now let's make the problem even more fun. Consider that the update to
libtevent might be coming in because it is necessary for a new feature
in libldb, which is in turn providing new functionality necessary for
SSSD. So now we have four packages all sitting in the same update. The
problem with this is that the tendency will be to only test the most
user-visible package(s) in the set. In this particular case, that might
be SSSD. So people would likely test SSSD and, if nothing went wrong,
consider the entire update stable.
But wait! SSSD isn't the only package that depends on libldb, libtevent
and libtalloc. So too does the samba package. Suppose that the bugfix in
libtalloc, after resolving the original issue, results in exposing
another more serious bug in samba? Now we need to pull a samba update
into this same update series.
A contrived example, you say? That would never happen, bugfixes aren't
likely to do that. Well, for one example:
https://admin.fedoraproject.org/updates/FEDORA-2011-11845 In this
particular example, we knew up-front that it was going to necessitate a
rebuild of several dependent packages and we coordinated a single
release to address them. So in this case, the proper approach was to
bundle them together in a single update. This worked because we
specifically knew that the libtevent change was going to break other
But what about when we don't know that? Let's take another example:
In this case, there was a security bug reported against Firefox. Such
things are serious, and acted on quickly. However, the bug was actually
fixed in the nss package, and Firefox, Xulrunner and friends were
rebuilt against that nss package. The problem was this: the fix made to
the nss package introduced regressions in every other package that
depended on it. However, because the default install of Firefox
contained no issues, it rapidly received the necessary karma points and
the whole update was pushed to stable. It then broke nearly every
application in Fedora that relied on cryptography.
The problem here was sociological, not technological. The only package
that received testing was Firefox. It's hard to say without evidence
whether the problem would have been averted by having nss go through its
own update, but I strongly suspect that what we would have seen was
greater testing on actual nss features for that specific update.
Of course, we now have the same potential for an issue that I described
above: If we had separate updates for nss and for Firefox, chances would
be highly-likely that Firefox would be pushed to stable via karma points
rapidly, whereas nss (which requires much more careful testing) might be
left behind in updates-testing.
So I really see two options for improving these situations:
1) https://fedorahosted.org/bodhi/ticket/663 I opened this ticket two
months ago (to silence). The idea would be to add the ability for bodhi
updates to mark other updates as a dependency, so that in the example
above, Firefox could have been marked as ready for stable, but not
pushed until the nss update was also marked as ready for stable. This to
me seems like the best long-term solution. I'd also like to mention that
Ubuntu's Launchpad system has this capability.
2) We could continue on the "single update for multiple packages"
approach, but revamp the karma system so that each SRPM gets its own
karma, rather than the update as a whole. Then, the whole update would
not be pushed via autokarma until all of the dependent packages had
sufficient karma (or the owner of the update could push them after the
stable wait period, of course).
Just a friendly reminder: If you are a Fedora account system account
holder, and haven't changed your password and uploaded a new ssh key
since we announced the mandatory change, you best do so NOW. The
deadline is 2011-11-30 (only 2 days away).
If you don't, you may no longer have access to groups you currently do
(like packager, or sysadmin or ambassador).
Go take a few minutes, read the announcement and security information
linked to it, and change your password and upload a new ssh public key.
If you aren't a Fedora contributor, the information linked in our
announcement is still a great read and may just help you be more secure
on your machines. :)
devel-announce mailing list
As you're aware, as of F15 we changed our default init system from
sysvinit to systemd. But we have lots and lots of packages with
daemons, and not all have thus far been migrated. Some maintainers
haven't responded, some are too busy, some aren't sure how to go about
it. In many cases, unit files have been posted by helpful individuals
(Thanks Jóhann B. Guðmundsson!) but they're not yet in the packages.
If you're a Provenpackager, check out these two tracking bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=713562https://bugzilla.redhat.com/show_bug.cgi?id=751869 (mostly this one)
And have a look at:
Look through, find something that looks manageable, and volunteer.
Most maintainers will be receptive, I think, but remember, offer/ask
before jumping in. If they're not responsive, we'll cross that bridge
Thanks in advance!
in your fear, seek only peace
in your fear, seek only love
Trying to build gforth with gcc 4.7 fails currently. The forth engine is
build but it fails its included tests. The problem is that every newline
the forth engine writes is replaced with 0x00 as seen in following diff:
0000010: 6566 696e 6564 2047 4458 2020 594f 5520 efined GDX YOU
0000020: 5348 4f55 4c44 2053 4545 2054 4845 2053 SHOULD SEE THE S
0000030: 5441 4e44 4152 4420 4752 4150 4849 4320 TANDARD GRAPHIC
-0000040: 4348 4152 4143 5445 5253 3a00 2021 2223 CHARACTERS:. !"#
^^ actual output
+0000040: 4348 4152 4143 5445 5253 3a0a 2021 2223 CHARACTERS:. !"#
^^ expected output
0000050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123
Removing -O2 from the compiler commandline fixes it, but I have no idea
why this happens. Does anyone have an idea how this can be solved?
I'm afraid I've just orphaned the insight debugger.
It now miss dependency iwidgets, that was a working up-to-date package
orphaned after the forced password change of last year, unperformed by
the iwidgets package owner.
I don't want to start I new troll on this subject: this has already been
widely discussed :-(
But my total disapprobation about this practice encourages me to not
continue support for this product.
If someone wants to adopt this package, please do.
httpd 2.4.1 packages are ready for dist-f18 and will be built early next
week. Rebuilds will be required for all packages containing httpd
modules. There are API changes in 2.4, so module packages may need
patches if upstream has not done that work already:
There are some significant changes in the packaging, also:
1) Config changes: I've moved to a minimal default httpd.conf which is
very close to what we're shipping upstream.
a) I'm proposing to split out packaged config snippets from mutable
config, with the former in /etc/httpd/conf.modules.d/, containing only
LoadModule lines, and ordered to avoid load-ordering issues.
b) /etc/httpd/conf.d/*.conf should contain no LoadModules for packaged
modules, and only any reasonable default configurations.
2) Loadable MPMs! MPMs are now loadable modules, so we only need to
ship one httpd binary again. Changing MPM is a config tweak.
3) Content. Putting unmutable content in /var was bad practice, so I've
moved the /var/www/manual and /var/www/icons to into /usr/share/httpd.
We now ship /var/www/* as empty directories.
4) Filesystem locations have moved in-line with upstream, e.g. apxs is
now in /usr/bin. /etc/rpm/httpd.macros has macros for everything module
packages should need.
Since much of the above requires packaging changes for module packages,
I've prepared a draft packaging guideline to document best practice:
If anything there looks stupid, needs fixing, is missing, or there's any
other feedback, please shout!
I'm interested in getting Plug http://piorekf.org/plug/download/
included in Fedora, this is a package that supports control of the
Fender Mustang range of amplifiers via USB, licensed under GPL3. It
has dependencies on qt4 and libusb and is currently packaged through
OpenSUSE. I've looked at the spec file and there are some minimal
changes required to build on fedora and pass rpmlint. So, what's the
next step? If necessary I can volunteer to maintain it myself (and
would have to volunteer as a maintainer), but would be more than happy
for someone else to take it.
Minor issue that still needs sorted out with .spec file: the source is
hosted at bitbucket, which means that the source package gets
downloaded through a redirection URL by commit id and also contains an
extra subdirectory level, I haven't found a REST request yet that can
get round that.
Thanks for your time,
Following is the list of topics that will be discussed in the FESCo
meeting today at 17:00UTC (1:00pm EST, 19:00 CEST) in #fedora-meeting on
Links to all tickets below can be found at:
= Followups =
#topic #699 Proposal to remove the package "tzdata" from Critical Path
#830 F18 Feature: ARM as Primary Arch --
= New business =
#829 New sponsor request: Pavel Alexeev (hubbitus)
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.