First I want to thank all of you for your excellent
work with Fedora and I hope I'm not in the wrong place
for making a proposal for a new software. If it's the
case, please let me know how to do it properly.
I'm developing an application called K3DSurf which is
a program to visualize and manipulate mathematical
models. It's also a "modeler" for Pov-Ray.
For more informations, please visit :
For any suggestion or question, just let me know.
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
Just a heads-up: Upon upgrading to evolution* 2.3.8 this afternoon I
noticed that I could not use any of my address books:
I localized the error to e-d-s - downgrading evolution only to 2.3.7
does not work, but downgrading evolution-data-server as well solves the
While doing so I noticed something funny: I was rpm -Uvh --force'ing the
old e-d-s package, and a symlink (libedataserverui-1.2.so.6) became
dangling. e-d-s 2.3.7 has it pointing to so.6.0.0 while 2.3.8 has
so.6.0.1 .. is this specific to the way e-d-s is packaged or more
On Wed, 24 Aug 2005 19:15:06 +0800, Jeff Pitman <symbiont(a)berlios.de> wrote:
> On Wednesday 24 August 2005 07:59, Pete Zaitcev wrote:
> > This happens when module yenta-socket is built statically into
> > kernel, which is how stock Fedora kernels are built.
> Not here. Unless I'm missing something.
> [root@kubik log]# uname -r
I should have not used "stock Fedora" but "stock Rawhide".
[zaitcev@niphredil ~]$ cat /proc/version
Linux version 2.6.12-1.1483_FC5 (bhcompile(a)porky.build.redhat.com) (gcc version 4.0.1 20050810 (Red Hat 4.0.1-8)) #1 Sat Aug 13 20:41:53 EDT 2005
[zaitcev@niphredil ~]$ grep YENTA /boot/config-2.6.12-1.1483_FC5
FC4 uses the old PCMCIA system with cardmgr (from pcmcia-cs RPM)
and FC5 uses the new system with pcmciautils.
BTW, this is a smaller problem than I thought. I'm going to throw
together a script for /etc/rc.d/init.d/pcmcia. I ass-ume that
yum will handle the details automagically despite the name of
the script conflicting. Or perhaps I should use pcmcia-yenta.
I do not like to add scripts, because our boot times are atrocious
even as they are. However, I do not have a better idea. The udev
simply is not involved here. Socket startup has to happen before
udev can receive any plug/unplug messages.
Hi, Dave, hi, Jeff:
Do you happen to remember why is eepro100 enabled in FC5 kernels?
I know that a few PCI IDs are not present in e100, seemingly without
any system to it.
The eepro100 was unmaintained for years now. Right?
As the editor of Red Hat Magazine, I receive a lot of article
suggestions. I ran across one recently that sounded like a good idea. Is
anyone interesting in writing an article about "reading" source code as
a way to start contributing to open source? i.e. Start with submitting
patches, eventually get a few patches accepted, then start writing your
own apps based on what you've learned from reading source code.
If you are interested, email me directly and we can discuss.
Editor, Red Hat Magazine
I found that PCMCIA does not work on Rawhide with pcmciautils on my test
laptop. The problem is that /sbin/pcmcia-socket-startup is not run.
This happens when module yenta-socket is built statically into kernel,
which is how stock Fedora kernels are built. If yenta-socket is loaded
as a module, /sbin/udevsend gets an event, and udev runs
pcmcia-socket-startup because of a rule in /etc/udev/rules.d/pcmcia.rules:
So, the question is: how do I make udev to run pcmcia-socket-startup
on boot if /sys/class/pcmcia_socket/ is not empty? Can I run custom
scripts on startup of udev? Or should I run this from
/etc/rc.d/init.d/pcmcia? Running this program twice appears
to be harmless, so if udev is restarted it should be no problem.
Since I'm sure there's other people around with fun hardware that just won't
work with the FC4 install kernel (Some of our IBM blades, Sun v40z), I'm
sure people would appreciate a "I just want to get it running and not mess
with rebuilding the entire damn distro with anaconda-runtime, which isn't
that well documented anyway" HOWTO :-).
Written from a PXE/kickstart point of view, if you want to do CD installs on
affected boxes, doing the full anaconda-runtime mess is probably easier.
I just wanted something with minimum possible changes to the install tree
and have unaffected boxes use the vanilla install images.
# Grab buildstamp from FC4 initrd
zcat /tmp/fc4-initrd.img | cpio -i
# Include it into rawhide initrd. Make initrd look for stage3.img instead so
the original can be kept for unaffected boxes
zcat /tmp/rawhide-initrd.img | cpio -i
cp .buildstamp .buildstamp.orig
cp ../initrd-fc4/.buildstamp .
find . | cpio -c -o | sed 's/stage2.img/stage3.img/;s/hdstg2.img/hdstg3.img/;s/netstg2.img/netstg3.img/' | gzip -9 > fc4-rawhide-initrd
# Add modules from rawhide kernel to stage2
mount -o loop stage2-fc4.img /mnt
mount -o loop stage2-from-development.img /mnt2
(cd /mnt; tar cvf - .) | (cd /tmp/stage2; tar xf -)
cp /mnt2/modules/* .
mkcramfs stage2 stage3.img
(repeat for hdstg2 and netstg2 if required and rinse)
PXE boot rawhide kernel & modified initrd for affected boxes and Enjoy (tm)
:-). Obviously you'll want an updated kernel getting installed in your
kickstart, or the box might not boot afterwards.
Would be nice if this was somewhat easier and/or someone actually made
(semi-)official updated installer images available ;)