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,
The way we currently install Eclipse plugins in Fedora is incorrect and
RPM places all the plugin artifacts in the proper directories. However
that does not update the eclipse metadata. This means that until the
next time eclipse starts it is unaware of the newly installed plugins.
Because the user would normally run Eclipse not as root Eclipse does not
have permission to write to the meta data files located in the
installation directory. It therefore creates a parallel version in the
user's home directory ~/.eclipse. This creates a fragile installation
and leads to a whole host of problems.
To improve this I have written apatch which runs the Eclipse reconciler
during rpm installation. The Eclipse reconciler is an Eclipse
application which goes through and checks the installation directories
and updates the eclipse metadata with any newly installed plugins.
To add support for this in your eclipse package you have to add the
following line to your rpm spec file:
%_eclipse_pkg [package name]
Here is an example from the eclipse-rse spec file for the
The above macro expands to the following:
if [ $1 == 0 ]; then
I apologize if you have experienced instability in Eclipse installations
on rawhide, it is probably due to these changes. Please let me know if
you have any comments questions or suggestions.
I will be filing a request to update the Eclipse packaging guidelines.
If you are interested in the details of the work, here is a summary in
the form of a patch: http://fpaste.org/pPEC/
I am orphaning the techtalk-pse package because the Gtk2::MozEmbed perl
module will no longer be maintained in Fedora because gtkmozembed
support has been removed from xulrunner.
If upstream (or anybody) has the time to work on techtalk-pse and get it
working with something like Gtk2::WebKit, I'm glad to pick up package
maintenance again. (I would, but my perl skills go as far as running
Ian Weller <ian(a)ianweller.org>
\/"/_ All Hail the Beefy Miracle!
I just orphaned gdk-pixbuf in pkgdb.
It failed the mass rebuild, not much left that depends on it, and
nothing I need. ;)
% repoquery --source --whatrequires gdk-pixbuf
So, if anyone really really really wants to keep it alive, feel free to
take it and fix it so it builds and works. ;)
It looks like I'll be taking over mythtv packaging for RPM Fusion and
I noticed it still only uses a sysv init script.
In the sysv script it sets some ACL permissions on video and audio
devices necessary for the backend service, and then on shutdown
changes it back.
I don't see any way to accomplish this in a systemd unit file other
than running a script.
What's the right way to do this? I have a template unit file (not
meant to "work" yet):
Description=MythTV backend service
Following is the list of topics that will be discussed in the FESCo
meeting today at 17:00UTC (1:00pm EDT) in #fedora-meeting on
Links to all tickets below can be found at:
= Followups =
#topic #667 Request to fix CRITPATH update process
#topic #663 Late F16 Feature Java7
= New business =
No new tickets since last FESCo meeting.
= Fedora Engineering Services tickets =
= 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.
No matter how far down the wrong road you've gone, turn back.
Up to now the glusterfs and hekafs versions and releases have been the
same for f16 and rawhide, i.e.: glusterfs-3.2.4-1.x86_64.fc16.rpm,
glusterfs-3.2.4-1.x86_64.fc17.rpm, hekafs-0.7-16.x86_64.fc16.rpm, and
I did that because the source, thus far, is exactly the same for both
f16 and rawhide. In f16 and rawhide both glusterfs and hekafs used sysv
Now for rawhide I'm going to switch to systemd. I know I can't switch to
systemd for f16, so the question is, what scheme should I used for the
One thought I had was to 'leapfrog' increment the release numbers. I
already have: glusterfs-3.2.4-1.x86_64.fc16.rpm and
glusterfs-3.2.4-1.x86_64.fc17.rpm. Then for the systemd version then I'd
go to glusterfs-3.2.4-2.x86_64.fc17.rpm. And if I need to respin
glusterfs I'd use glusterfs-3.2.4-3.x86_64.fc16.rpm and
current 3.2.4-1.fc16 [i] 3.2.4-1.fc17 [i]
new... 3.2.4-2.fc17 [s]
3.2.4-3.fc16 [i] 3.2.4-4.fc17 [s]
([i] means init.d, [s] means systemd)
Alternatively I could just add a character to the first release using
sytsemd for rawhide, e.g. 's'. Then I'd have the existing
glusterfs-3.2.4-1.x86_64.fc16.rpm and glusterfs-3.2.4-1.x86_64.fc17.rpm,
and glusterfs-3.2.4-1s.x86_64.fc17.rpm for the new systemd version. And
for a respin then I'd just use systemd going forward for rawhide, and
I'd use glusterfs-3.2.4-2.x86_64.fc16.rpm and
current 3.2.4-1.fc16 [i] 3.2.4-1.fc17 [i]
new... 3.2.4-1s.fc17 [s]
3.2.4-2.fc16 [i] 3.2.4-2.fc17 [s]
Whichever I go with I'd do the same thing for hekafs.