I'm the current Fedora maintainer of the twinkle package.
Sadly, it's in poor shape:
- Segfaults on start in recent fedora versions (depending on config).
- Has not had an upstream release in 4+ years.
- Has not had any response from upstream maintainer in at least that
- Uses Qt3 and a complex stack of c++ libraries.
- 8 open bugs:
Debian removed it last year, Arch moved it to a user repo instead of
the main repo last year.
So, I am going to retire this package in rawhide soon unless there's
folks with a very strong C++ background wishing to fix issues and
basically become the new upstream.
although package Docky was lot of work for me (licensing patching etc) I
am no longer using it and last two releases were very unstable. There
are couple of bugzillas reported mainly because of gconf migration.
Docky is an advanced shortcut bar that sits at the edges of your screen.
It provides easy access to some of the files, folders and applications
on your computer, displays which applications are currently running,
holds windows in their minimized state and more.
Docky is written in mono.
Please ping me if you are interested to maintain the package.
Lukas "lzap" Zapletal
PHP opcode cache is a very important feature for sites with large traffic.
APC is mostly a dead project.
No stable release for php 5.4, lot of issues.
Upstream move most of dev resources to new "Zend OPcache" which will be
the official opcode cache, integrated in PHP 5.5.0
To be able to drop this package, we need
1/ php-pecl-zendopcache, the Zend OPcache for php 5.3 / 5.4
Target version is EPEL-6 and Fedora <= 18 as Fedora >= 19 already have
php-opcache (subpackage of main php, same code)
2/ php-pecl-apcu, APCu, the drop-in replacement of APC for user data cache.
Target versions : Fedora >= 18 and EPEL-6
Please, review this.
-----BEGIN PGP SIGNED MESSAGE-----
On Sun, 12 May 2013 17:56:20 +0200
Christoph Wickert <christoph.wickert(a)gmail.com> wrote:
> back in April we discussed the F19 spins and it was widely agreed
> that http://fedoraproject.org/wiki/Releases/19/Spins is the canonical
> list of approved spins that need to be produced. However this doesn't
> seem to be the case, I only see the desktop spins. In fact, that is
> not even true given that I cannot find MATE either.
> What does the spins SIG need to do in order to get the remaining
We have for the last few releases composed the 5 main desktop spins
Gnome, KDE, LXDE, XFCE and SoaS for Alpha and Beta and in theory
nightlies have been used for QA. before making the 5 we only made KDE
and Gnome. QA has not been really happening as is evidenced by spins
regularly failing to compose, and being shipped DOA, as in the
design-Suite in F18 and Games being dropped for failing to compose. I
personally fixed a bunch of spins in F17.
For Fedora 19 I'm planning to only compose those 5 for GA also and I
will only be shipping them if they have been tested and signed off by
at least 3 people as working. This is due to Spins having been shipped
broken in the past. I think we need to stop pretending there is a spins
SIG as its not been functional or working for a few years.
Perhaps the question we really need to ask is how should we deploy and
install Fedora, Which is not something we can change or solve for f19
or probably even f20. An idea that comes to mind is to have package
selections and post install config tasks ship as kickstart snippets
with the DVD. we then use grub/syslinux to present a menu to the users
to have different frameworks that resemble the spins the kickstart is
fed to anaconda then at boot time or anaconda gives you the option to
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
-----END PGP SIGNATURE-----
Hi, i just tried to compare my F17 system with F19 pre-release and found
something odd in my F17 system:
19:08:26 up 2 days, 10 min, 5 users, load average: 0.18, 0.28, 0.31
# systemd-analyze time
Bootup is not yet finished. Please try again later.
A very funny message. :-)
What does count for systemd/systemd-analize as 'booted''?
Obviously some sort of flag is not being set or something similar,
because the system is fully operational.
# systemd-analyze blame | head -3
Nothing strange here, the system "boots" relatively quick.
Thanks in advance.
Dear Fedora community,
several months ago, at the Developer conference in Brno, Software Management
team received a whole bunch of proposals for new functionality in RPM and
related software stack.
We acknowledge the need for some changes in Software Management stack in
Fedora but we don't want to make changes just by guessing what our
users want. Therefore I call to you, consumers of our products (dnf, yum and
rpm): what are the changes that you would like to see in the foreseeable
future (say 2-3 years) and why would you like to see them (what would they
help you with)?
There is already a list of some RFEs on rpm.org wiki, you can use it as an
inspiration, to see what RFEs we have already received:
The only limitation for your requests is our manifest which defines the scope
of SW management stack for the future. It is attached to this email (note that
it's quite extensive but the first part should give you a good image of what is
the planned scope of SW management stack).
Please send your requests as replies to this email so they can be properly
After your proposals are filed and discussed, all will be evaluated by our
team and a roadmap with priorities will be created with those selected as
doable and meaningful.
Thank you in advance for your participation
few days ago I was explaining to someone*, what the Developer Assistant
When I said something like: "...and you project is exported directly to
GitHub  if you want", the person I was talking to interrupted me and
asked an interesting question:
Why our own tools prefer a proprietary service, such as GitHub, over our
own infrastructure (Fedora Hosted.org)?
The answer is very easy: Because developers prefer GitHub over Fedora
Hosted and we want to target on the majority.
That leads us to other question: Why do developers prefer GitHub over
Of course not each developer uses Fedora etc., but even many of our own
projects are usually hosted on GitHub or Bitbucket - see Developer
Assistant itself or Yumex as an example. Try to search Fedora on GitHub .
But other reason is, Fedora Hosted user/developer experience is way
worse than GitHub's. Even for a registration or a small change you need
to create a ticket, there is no interface for pull requests or similar
things (or not that I am aware of). Browsing the projects (user
I would like to change that and make Fedora Hosted infrastructure
something, that can compete GitHub. Or at least provide a service that
developers using Fedora would consider as a choice.
What about running something as GitLab  or Gitorious  on Fedora
Hosted, add continuous integration for creating repos with nightly RPMs,
integrate it with FAS, brand it with Fedora graphics, add more stuff and
make it cool. Simply provide a truly open alternative for developers
that not only develop free software, but also are interested in freedom
Than we can provide our own service, that our tools can integrate with
as default. I don't except developers will leave GitHub and move to
Fedora Hosted, so there is nothing wrong on supporting GitHub in our
tools. But wouldn't it make more sense to promote our own services at
the first place? Why support a company that makes profit and is not
related to Fedora at all?
Of course you can argue that Fedora's main goal is not to provide free
software hosting service, but then why we offer Fedora Hosted in the
first place, right?
* I haven't got time to ask for permission to publicly quote this person
about this on the list, but if you are the person and want the
attribution, feel free to say it :)