I always wondered why Red Hat never upgraded to the latest stable Tcl/Tk
8.4.4 release (more performant and with bugs fixed), but instead sticks
to the 8.3 series. Suse and others I believe have been using it for a while.
Let me know if I can help (I make Tcl/Tk 8.4.4 rpms available on my
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
Jean-Luc Fontaine mailto:firstname.lastname@example.org http://jfontain.free.fr/
As Yum is very handy, it gets harder and harder as time pasts to
go to the sites and download RPMs manually, so here I propose the
following features. Let me know if they are already implemented
/ there's something wrong with them / ...:
1. Some way to install SRPMs. When you are testing a distro, it
comes quite handy to install the SRPM with a single yum command
when you find a bug and want to look at.
2. A way to force reinstall of a package. If by any chance I get
one of my packages corrupted, the way I do right now is to rpm -e
--nodeps it and then yum install.
3. A way to find out which repo contains the currently installed
version of a package. It comes quite handy when you want to
install SRPMs. Currently I have to guess, or go around all
4. A way to downgrade a package (say for the moment, that's ok if
update overrides that).
On a side note: Is there any way, to keep updated on both 2.4
and 2.6 kernels? Without renaming one of the to say
Hi again gang...
I have an interesting idea. What if we included an "Open Music" item on
the FC desktop?
How exactly could this work? Well, there are several ways, but two ways
I can think of right off the bat are:
Including songs from Open Artist:
You could directly include a handful of songs from Open Artist into the
Fedora Core distro.
Providing download links in "Open Music" desktop folder:
With this method, you could include more music, by simply pointing
people to links where people can freely download said music.
I guess the above begs the questions: What is Open Music? Where are
these types of artist? What license would be viable in order to allow
Fedora to package and ship these songs. Would linking allow for slightly
less restrictive licensing.
I mention it because I personally would like to make some of my music
available where it could be traded and listened to. My feelings are
that if people enjoy what we are doing, then they'll come to our shows,
buy physical copies of our CD's, or find other ways to support us in our
Another nice thing is that it would allow people to see that yes, you
can have music on your Linux desktop.
Thanks for your time,
Trae McCombs -- vocals, bass
I would like to make a proposal/request in the hope of soliciting
feedback and ideas.
Short summary: There should be a standard path supported by the
distribution where RPM packages can install custom/updated kernel
modules and know that the modutils will search there first before
searching the path containing the distribution supplied modules in the
As part of supporting some of my systems I need to provide custom kernel
modules. For example, two that I use frequently are Sangoma WANPIPE
drivers (the ones that ship with the kernel are ancient) and the PPP
MPPE compressor for PPTP support (the MPPE module requires a new
ppp_generic.o). Because I strive for a fully RPM managed system I've
been doing my best to produce clean RPM packages to manage these
The problem that I encounter is that both of these kernel module updates
need to replace files that are provided by the Red Hat/Fedora supplied
kernels. There is no mechanism that I have found in RPM to specify that
files can be "stolen" by new packages so if I try to install RPMs with
the modules to the standard locations I need to use --force to overwrite
the existing files - which I don't consider a good solution in general
and it is particularly bad when you are using something like apt/yum.
The solution I have seen a number of times is to package the file in the
RPM named differently and then use post-installation scripts to rename
the old kernel module out of the way and then rename the new one in it's
place. While this does avoid the --force issue it violates the spirit
of package management and RPM "owning" the files and it breaks --verify
runs on the kernel packages.
What I have found to be the only good solution so far is to setup a new
module path in /etc/modules.conf so that modutils searches that first
and then if it doesn't find the module there then proceeds to the
standard kernel location. So I have tested some RPMs that setup
/etc/modules.conf to look something like:
Then I have the RPMs install the modules in the /lib/modules/custom
hierarchy and they are found there first.
This has worked well for me and seems to meet all the requirements from
a packaging standpoint.
I would like to request that whoever is in charge of modutils/kernel
module issues (presumably someone @redhat.com) take a look at this idea
and codify a standard path that is searched first and setup by default
with the distribution so that there is a standard mechanism all kernel
module packagers can take advantage of in a consistent fashion.
Any comments and suggestions are welcome.
sorry if this is a double posting. But in Fedora beta 3 release 0.95
(Severn) i found a translation error in the Menu. Under System
Configuration (Systemeinstellungen) i found "Drucke" instead of
"Drucken" or "Drucker" (print, printer)
Where can i told this failsure? in bugzilla.redhat.com?
PS: Sorry i posted this at the first time on fedora-docs-list, that was
In Gnome info and man pages are accessible using yelp.
Now, a lot of packages have manuals in html, ps or pdf,
usually in /usr/share/doc. These docs too should be accessible
via yelp, opening the appropriate viewer if clicked.
Of course, this would require a little help from the packager.
Somehow a piece of documentation would have to registered.
For some reason librsvg is not linked against libcroco, meaning that
nautilus crashes because of a missing symbol in librsvg-2. Everything
else works because the gtk-engine and gdk-pixbuf plugins are linked
against libcroco. I'm still at a loss about this one because nautilus
*was* working fine until I clicked on a PNG and nautilus died. Checking
~/.xsession-errors revealed the tell-tale:
nautilus: relocation error: /usr/lib/librsvg-2.so.2: undefined symbol:
$ LD_PRELOAD=/usr/lib/libcroco.so.1 nautilus
works as expected. I still don't know why it managed to start the first
time or why it died, but I do know that ldd /usr/lib/librsvg-2.so.2.4.0
reveals no link to libcroco.so.1 (as should be expected).
Shahms King <shahms(a)shahms.com>
Why is it that Fedora comes with all the RPMS for acls and extended
attributes yet the kernel does not come with the bestbits patches to
enable you to mount a filesystem with acls and or extended attributes?
To make matters worse, the bestbits patches will not work with the
fedora core test3 kernel source. So you have to get a clean 2.4.22
kernel from www.kernel.org and apply the patches to that. Doing this
sort of defeats the purpose because you then loose all the patchs that
have been applied to the fedora core test3 kernel. Are there any plans
to actually apply the bestbits patches to the Fedora core kernel?
I will introduce myself as Gérard Milmeister did.
Full legal Name
Informix DBA & Linux System Administrator.
Centrale Lille -France-
My Goal in the Fedora Project
I would like to work for the moment for and with the RH Artwork Team.
Unfortunatly, I really do not know how to start and where can I find the to
do list as well as samples.
I know that I have not a great skills in the domain but I will do my best.
Thx for your answers.
Informix & Redhat Qualified.
I have used RedHat Linux since 1997.