I'm volunteering to run a GPG keysigning party at the FUDCon in
Raleigh in January. Keysignings are good ways to get to meet people
face-to-face (with a government-issued photo ID to boot!), and serves
to extend the GPG Web of Trust.
for details on how to send me your keys beforehand.
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
Related to Jesse's "I care when it looks like ass compared to the other apps I
have open" message in the recent K3b thread:
Getting GNOME apps to look decent in KDE sessions is somewhat painful
currently. Not only does one need to configure their settings in the GNOME
control center (which I can understand and live with even though it's
suboptimal), but that is not enough. No settings persist accross session
unless one gets something to start gnome-settings-daemon.
Without gnome-settings-daemon running, many GNOME apps display broken/missing
icons, and do not honor the settings I've configured in GNOME control center
(eg. font sizes, themes). For examples of broken icons log in to a fresh KDE
session, and open GNOME control center itself (the initial view shows lots of
broken icons) or the nm-applet context menus. For examples of my font size
being ignored, any GNOME app seems to do.
Where should this be fixed? Shouldn't GNOME apps that use settings governed
by the daemon get the daemon running if needed? Can't GNOME apps be made to
look semi decent (eg. no broken icons) without the daemon running? What if
gnome-settings-daemon isn't even installed? Should KDE start
gnome-settings-daemon when a session starts?
This is on F8. I've traditionally "fixed" this locally by installing a
~/.kde/Autostart/gnome-settings-daemon -> /usr/libexec/gnome-settings-daemon
symlink but I think this deserves a real fix somewhere so that things just
While searching for LTSP 5 for Fedora, I didn't find anything but this
bug report https://bugzilla.redhat.com/show_bug.cgi?id=234048. Also,
I've not found anything regarding LTSP in this list.
So, Is someone working on LTSP 5 support for Fedora? Is there some
repository were pick code from or anything?
Ok, I'm just throwing this out there for discussion.
We would like to migrate from Moin to another wiki.
We have yet to find any valid migration scripts that convert users,
What would YOU say if we made the current wiki read only, and made the
teams and people migrate important relevant content over to a blank wiki
by hand (copy and paste)?
I think this would also allow us to trim up the wiki a bit. So the
question I'm asking is if we decided to go this route. How many of you
would hate the Infrastructure group?
I've created a draft Feature page on the wiki to copy Debian's
common-lisp-controller package and methodology for installing Common
Lisp implementations and libraries.
This will require changes to all common lisp implementations in Fedora,
so I'm looking for support from those packagers (some of whom are on copy).
Also, this is not something I can do on my own. I'm hoping there are
like-minded people out there that are interesting in making Fedora a
great platform for deploying Lisp based infrastructure. So, are there
any willing to help over the next 6 months?
Some time back, there was a discussion on fedora-list about vanilla
kernels. IIRC, Rahul offered to create an RPM for the vanilla
kernel.org kernels with no Fedora patches or only security patches for
those of us that wanted to test with vanilla kernels. I am wondering
whatever happened to that proposal.
I have a Thinkpad T61 with nVidia graphics. In F8, the machine refueses
to suspend--it goes into suspend mode and then spontaneously comes out.
This happens with the nVidia driver and the VESA driver (the nv driver
still doesn't work 8^(...). In RHEL5, an identical machine running the
VESA driver works perfectly.
I'd like to try to help troubleshoot this
(https://bugzilla.redhat.com/show_bug.cgi?id=254214), and I think having
a vanilla kernel might be useful.
Clemson University Math Sciences
mjs AT clemson DOT edu
Before I go into the whole process of coming up to speed with the Fedora
packaging guidelines, etc, I wanted to ask here if anyone else here is
working on GNU Radio packages for Fedora.
If not, I'm going to work on such; it may take me a little time to come up to
speed with 'modern' packaging (it has, after all, been a little while since I
last spun a PostgreSQL RPMset, back in 2004). So I know I have a lot to
learn; thankfully, the documentation is far superior to what I remember in
2004 and earlier....
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
I'm working on implementing:
in our KDE packages. This is the current situation:
* KDE 4 uses an API called Sonnet for spellchecking. Sonnet already has an
enchant backend, and it is the default recommended by upstream. There's also an
aspell backend; we will probably drop the aspell-devel BR so we lose the hard
aspell dependency, aspell can be used through enchant anyway (using
enchant-aspell, which is about to be split into a separate subpackage according
* The situation in KDE 3 is more complex. We'll be stuck with several KDE 3
apps for a while to come, so I had to find a solution there too. As KDE 3 has
seen years of binary compatibility, there are 2 spellchecking implementations
- legacy KSpell: That API uses command-line spellcheckers using the "ispell
pipe interface". It doesn't use plugins, instead, everything is handled by 2
central classes. Rewriting this code to use libraries (e.g. enchant) properly
is a lot of effort for this legacy code. Thus, I patched it to support the
hunspell command line and its "ispell pipe interface" (which required only
The patch is preliminary, I still have to test that it works, and we also have
to make sure the defaults are set up so hunspell is used by default, at least
for new installations.
- KSpell2: This is the API KDE 4's Sonnet is derived from. It uses
spellchecking libraries and a plugin architecture. I backported Sonnet's
enchant backend plugin from kdelibs 4 SVN to KSpell2:
I did a minimum amount of testing on this one, it could probably use more. And
here too, we'll want to make sure it is the default, most likely by not
shipping any other KSpell2 backend.
This comes "fresh out of the presses". I haven't added these patches to the
Rawhide packages or submitted them upstream yet.