Unfortunately I don't have the time to proper maintain the
packages below. So I believe it is better to orphan them,
and have just done so.
If you're interested in any of these feel free to pick them up
bochs - Portable x86 PC emulator
I believe everyone is pretty much using qemu now. If not
I hope someone else will pick this up
crystalspace - 3d engine
I packaged this for 2 reasons:
1. so that people who wanted to develop code with it could do
so easily on Fedora
2. to maybe package some games which use this
2. never happened due to lack of good candidates. Currently
upstream has version 1.4, and we are shipping 1.2.x, so for 1.
this package also is useless unless upgraded (bug 585439).
cel - Crystal Entity Layer (CEL)
A scripting language for crystalspace
TnL - A futuristic action flight simulator game
Dead upstream, never really finished / completed by
TnL-data - data files for TnL
Io-language - programming language
I packaged this as a dep for TnL. Could also be useful
to some people by itself, needs an update to latest upstream
Java SIG pseudo user has been created with commit emails from monitored
packages flowing to java-devel mailing list (thanks to tibbs and mjw).
If you want java-sig to monitor and check your commits you can add
java-sig pseudo user to CC for your package. For old packages follow
. For new packages that you want to have monitored just add java-sig
to CC when asking for SCM. This is not mandatory (at least for now), but
still encouraged for java packages :-)
One thing to note: email of java-sig is java-devel mailing list
but emails will be comming as if from comitter's email address as
present in FAS (or from email it was set-up with it seems). Currently
java-devel ML is set-up to allow messages from @fedoraproject.org mail
addresses. It will reject commit messages from other email addresses. If
you add java-sig to CC and your commits will not get in, contact me
off-list and I'll add exception for your email address.
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
Red Hat Inc. http://cz.redhat.com
I am planning to push libnotify 0.7.0 into rawhide by the end of this
week; this is going to be a little painful, since there are some api
changes that will require minor adjustment of all users. And there's
quite a few of them (see below). I will hopefully be able to handle most
of the GNOME dependencies, for the rest I need to ask for some help.
Scratch builds of libnotify 0.7.0 rpms can be found here:
Here is an overview of the api changes:
notify_notification_new_with_status_icon is gone
notify_notification_attach_to_status_icon is gone
notify_notification_attach_to_widget is gone
notify_notification_set_geometry_hints is gone
notify_notification_new has lost its widget argument
A typical patch will look like this one:
For some background on these changes, see
Possibly affected packages:
[mbooth@t500 virt-v2v (f14)]$ git push origin f14
Total 0 (delta 0), reused 0 (delta 0)
remote: C refs/heads/f14 mdbooth DENIED by refs/heads/f[0-9][0-9]
remote: error: hook declined to update refs/heads/f14
! [remote rejected] f14 -> f14 (hook declined)
error: failed to push some refs to
I'm the owner of this package and I pushed to rawhide yesterday, so
permissions shouldn't be an issue.
On a related note, is there a fedpkg command which pushes to a branch?
The obvious 'fedpkg push' pushes only master regardless of which local
branch you're on:
[mbooth@t500 virt-v2v (f14)]$ fedpkg push
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
appframework -- Swing Application Framework
beansbinding -- Beans Binding (JSR 295) reference implementation
bindex -- Bundle Manifest Header Mapper
bytelist -- A java library for lists of bytes
cobertura -- Java tool for calculating the test coverage
felix-framework -- Apache Felix Framework
felix-main -- Apache Felix Main
felix-osgi-compendium -- Apache Felix Project: OSGi Compendium Bundle
felix-osgi-foundation -- OSGi Foundation Execution Environment (EE) Classes
freemarker -- FreeMarker template engine
ini4j -- Java API for handling files in Windows .ini format
javahelp2 -- JavaHelp is a full-featured, platform-independent,
extensible help system
jcodings -- Java Libraries for Ruby String Encodings
jemmy -- Java UI testing library
jvyamlb -- YAML processor for JRuby
netbeans -- Integrated Development Environment (IDE)
netbeans-javaparser -- NetBeans Java Parser
netbeans-platform -- NetBeans Platform 9
netbeans-platform8 -- NetBeans Platform 8
netbeans-resolver -- Resolver subproject of xml-commons patched for NetBeans
netbeans-svnclientadapter -- Subversion Client Adapter
If you have any questions about the packages then, please, contact me
via e-mail victor.g.vasilyev at gmail.com
Victor G. Vasilyev
Lack of decent profiling is a major problem for making our operating
system fast. By far the most effective of profiling is sampling profile
with callgraph information.
Soeren's comment from March:
Basically summarizes the situation, and as far as I know nothing has
changed ... with default compilation options, getting callgraph
profiling on x86_64 really requires a DWARF unwinder in the kernel.
Which seems unlikely to happen.
As a developer, your options for profiling are:
- Recompile everything you care about profiling
with -fno-omit-frame-pointer instead of using system packages.
- Switch to i386
Even if the second was reasonable to ask of developers, it also makes it
really hard to help users with performance problems if they have to
reinstall their system to give you a profile.
So, I'd like to bring up the possibility of switching to compiling our
packages with -fno-omit-frame-pointer for x86_64. As Soeren says, x86_64
isn't register starved, so the performance penalty shouldn't be huge.
But I have no idea if it's 0.5% or 5%.
What aspects of performance do we care about?
How would we measure the performance impact of changing
What is the acceptable slowdown?
(One downside of any slowdown is that if we take a 1% hit and do
performance work that makes the system 10% faster, then we look bad by
comparison with other Linux distributions who get the advantages of the
performance work but don't take the 1% hit. Still, we should do what has
the biggest net gain for our users, right?)
I would like to ask, when it will be possible to have kernel 2.6.35 with
/sys/module/drm_kms_helper/parameters/poll to disable "hotplug" polling.
I have laptop with i915GM video and experience mouse cursor freezes every 10 second.
This is all about: issue with "hotplug" polling on those systems,
Kernel 2.6.36 already has drm_kms_helper module parameter, but 2.6.35 still doesn't.