I have no more time to support the following packages in the Fedora.
jack-audio-connection-kit -- The Jack Audio Connection Kit
klamav -- Clam Anti-Virus on the KDE Desktop
man-pages-uk -- Ukrainian man pages from the Linux Documentation Project
python-alsa -- Python binding for the ALSA library
qstat -- Real-time Game Server Status for FPS game servers
uniconvertor -- Universal vector graphics translator
With Best Regards,
This is something I got in my mail box today.
As I don't have a valid answer for this, maybe someone else can answer for me?
the url of the blog of the guy: http://www.krisbuytaert.be/blog/
== the mail ==
Over the course of the day I recieved 22^3 mails from your friendly Bug Zapper.
Most of those bugs where bugs I had reported upon crashes using
bug-buddy. Bugs on different desktop tools such as .. synergy,
evolution, gwibber , gnome-settings and probably some others
I do understand that I development goes on and on .. and your fancy
devs don't care anymore about
bugs I reported on Fedora 12 as they are all hacking on Fedora 15.
But what I don't get is that non of these bugs was ever touched,
they've been automatically created , and automatically closed
<a href="http://tieguy.org/blog/2004/09/">Luis</a> already told us
ages ago .. that every project needs a bugmaster apparently Fedora
replaced that bugmaster with a Bug Zapper.
So can someone please explain my why I should continue to try to
improve Fedora by reporting bugs ?
I have been working for a few years (with Fabio Checconi) on a disk
scheduler providing definitely lower latencies than cfq, as well as a
higher throughput with most of the test workloads we used (or the same
throughput as cfq with the other workloads). We named this scheduler
bfq (budget fair queueing). I hope this is the right list for announcing
One of the things we measured in our tests is the cold-cache execution
time of a command as, e.g., "bash -c exit", "xterm /bin/true" or
"konsole -e /bin/true", while the disk was also accessed by different
combinations of sequential, or random, readers and/or
writers. Depending on which of these background workloads was used,
these execution times were five to nine times lower with bfq under
2.6.32. Under 2.6.35 they were instead from six to fourteen times
lower. The highest price paid for these lower latencies was a 20% loss
of aggregated disk throughput for konsole in case of background
workloads made only of sequential requests (due to the fact that bfq
of course privileges, more than cfq, the seeky IO needed to load
konsole and its dependencies). In contrast, with shorter commands, as
bash or xterm, bfq also provided up to 30% higher aggregated
We saw from 15% to 30% higher aggregated throughput also in our
only-aggregated-throughput tests. You can find in  all the details
on our tests and on other nice features of bfq, such as the fact that
it perfectly distributes the disk throughput as desired, independently
of disk physical parameters like, e.g., ZBR. in  you can also find
a detailed description of bfq and a short report on the maturity level
of the code (TODO list), plus all the scripts used for the tests.
The results I mentioned so far have been achieved with the last
version of bfq, released about two months ago as patchsets for 2.6.33
or 2.6.34. From a few days a patchset for 2.6.35 is available too, as
well as a backport to 2.6.32. The latter has been prepared by Mauro
Andreolini, who also helped me a lot with debugging. All these patches
can be found here . Mauro also built a binary kernel package for
current lucid, and hosted it into a PPA, which can be found here .
A few days after being released, this version of bfq has been
introduced as the default disk scheduler in the Zen Kernel. It has
been adopted as the default disk scheduler in Gentoo Linux too. I
also recorded downloads from users with other distributions, as, e.g.,
Ubuntu and ArchLinux. As of now we received only positive feedbacks
from the users.
 Ubuntu PPA: ppa:mauro-andreolini/ubuntu-kernel-bfq
> > I have to second someone taking over rrdtool. I handed it off to
> > Chris
> > a while back, but have still done far more work on it since then
> > he has, and I've not seen him touch an rrdtool bz in ages. :(
> > (And no, I don't want maintainership back.)
> I am ready to take it (I already own it in RHEL). I think all steps in
> non-responsive maintainer process have been fulfilled
Please could any FESCo member approve the takeover of rrdtool (according to nonresponsive package maintainers policy)? Or should I open ticket for this?
Christopher Aillon <caillon(a)redhat.com> wrote:
> I missed the first notice of this go by, but I use zsh so can play with
> it in the next few days. Can you post the updates so I don't hit the
> same bugs you did?
Sure. Attached. The bugs were mainly with zsh conventions and getting
the sed command for the branch selection corrected.
we use mock for local package build, but it's very slow. now we install
a new host just for mock with 8core, ram disks etc. it seems it still
slow. first of all most of the time mock use only one 1 core of the cpu.
is there any way to speed up different part of the mock build process?
thanks in advance.
ps. anyway is there any better place to discuss it?
Levente "Si vis pacem para bellum!"
I'm currently in process of automatic enlisting of all ~10K Fedora Git
repos at Ohloh. Right now roughly 7% of repositories were added and
overall process will be finished in a 20-30 hours (it takes me about
5-10 seconds to properly add repository, and I don't want to speedup
this process - to prevent Ohloh from accidental DoS).
With best regards, Peter Lemenkov.
Few days ago I started to get very usefull notifications that my
critical package, mingetty-1.08-6.fc13, `has been in 'testing' status
for over 2 weeks, and has yet to be approved.'
I doubt such mails help me as the package maintainer, because according
current Updates policy
<https://fedoraproject.org/wiki/Updates_Policy#Updates_to_.27critical_path...>, I can only wait to some (proven) testers to test my package.
I think better place to send such allerts is proven-testers mailing list
/ alias (does not exist amazingly) or
<test-announce(a)lists.fedoraproject.org> mailing list.
I'd like to request persons reposnsible for forcing and implementing
Update Policy and bodhi notification system to re-eavaluate current
configuration in spot of this concerns and to make package update
process more friendly for all involved people.