* Tue Mar 16 2004 Jeremy Katz <katzj(a)redhat.com> - 0.34-1
- use vmlinuz for ppc now
* Mon Dec 01 2003 Jeremy Katz <katzj(a)redhat.com> 0.33-1
- no ide-scsi with 2.6
* Fri Nov 28 2003 Jeremy Katz <katzj(a)redhat.com>
- add buildrequires (#111150)
* Thu Apr 15 2004 Jeremy Katz <katzj(a)redhat.com> - 0.141-1
- xserver.py: workaround libxf86config not writing out the monitor stuff
we tell it to (#120950)
* Wed Apr 14 2004 Jeremy Katz <katzj(a)redhat.com> - 0.140-1
- translate.py: one more try at string encoding madness (#119391)
* Tue Apr 13 2004 Jeremy Katz <katzj(a)redhat.com> - 0.139-1
- videocard.py: fixups for VESA handling on x86_64
- videocard.py, xserver.py: XFree86 -> Xorg changes
I'll describe first the situation, and the actual question is at the
I'm speaking from the perspective of electronic musicians and sound
geeks - i'm using Linux to run sequencers and other MIDI software, JACK,
DAW applications, external synths and effect boxes interfaced via MIDI
and analog audio, etc.
And i'm running all that on Fedora.
For this kind of usage, up-to-date sound drivers are essential. ALSA has
been fixing bugs and adding new useful features at a steady and rapid
So far, on distributions based on kernel-2.4 (Red Hat 9, Fedora Core 1),
i was content to download the ALSA rpms from http://freshrpms.net/ ,
rebuild the src.rpm, install the binaries and i was good to go. Because
ALSA and the kernel were essentially decoupled, nothing prevented me
from keeping up with the newest ALSA (short of small occasional
incompatibilities between ALSA and the Red Hat modifications to the
This helped me a lot with my work. It allowed me to get new improved
mixers when they were ready, it allowed me to squish bugs out of the
But i wonder about Fedora Core 2. That one will be using kernel-2.6,
which includes ALSA. Typically, a Red Hat / Fedora release does not
increment the kernel version during the release cycle. That means that
FC2 and beyond will get stuck with whatever ALSA version was available
at release time.
For anyone using Linux for sound / music work, that is not ok. If you
buy a piece of hardware (e.g. an expensive professional sound card such
as an RME Multiface) and an essential feature is only supported by ALSA
versions newer than what your distribution provides, then... well, it's
not the end of the world, but it's definitely not good.
Sure, one could compile a newer kernel, but that way the Red Hat changes
to the kernel (which are often good for demanding apps such as digital
recorders) will be lost.
Long story made short, is there any mechanism provided by Fedora Core 2
to allow users to painlessly upgrade to newer ALSA versions without
having to ditch the kernel bundled with the distribution?
I am trying to build the ndiswrapper module on FC2, test2. This uses the Makefile in
/lib/modules/2.6.5-xxx/build. The compilation fails because
/lib/modules/2.6.5-xxx/build/Module.symvers is missing. I am using the
latest kernel from rawhide. It used to work with an older 2.6 in FC1.
I'd like to get some testers for the packages I made this weekend for
this network card. The two bugzilla entries relevant to this are
I built packages for three FC1 kernel releases (the base one, and the
two latest ones), for up and smp, and for i686 and athlon.
Don't forget to install the firmware file for this driver in
Ville, and other interested people, I'd really like us to move forward
on packaging kernel modules for fedora.us and developing some standard
for it. I have a simple template tarball working with autotools that
makes it really easy to package external kernel modules for 2.4, and
hope to extend this sometime soon to 2.6 too.
Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
what good are promises
if nobody honours them ?
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/
When I attempted to install from these two days onto my x86_64 box,
Anaconda just gets stuck in both GUI and TUI mode right after I tell it
that I want to run Disk Druid for manual partitioning. In VT2 top shows
that anaconda is using 100% CPU and appears stuck that way forever.
Is there any way I can debug this from VT2? I couldn't figure out any
way with the available tools there.
I'd like to call on everybody, who's maintaining packages, to no longer
use "Requires(foo,bar): ..." notation in spec files, because it can lead
to unexpected results due to two bugs.   Details in the bugzilla
Instead, it should be split like this to work around those bugs:
For instance, we here have a package with "Requires(post,preun): GConf2"
because gconftool-2 is needed and executed in the package's postinstall
and preuninstall scriptlets. However, the installed package does not seem
to depend on GConf2 when it is queried like this
$ rpm --query straw
$ rpm --query --whatrequires GConf2 | grep straw
and actually one can erase the GConf2 package (provided that no other
installed package depends on it, of course, which makes this bug more
dangerous when less widely used programs are required in package
scriplets). A subsequent "rpm --erase straw" would fail in the
preuninstall scriptlet, since gconftool-2 is no longer available.
 Requires(pre,postun) screws up package ordering
 Requires(pre,postun) is ignored for installed packages
Fedora Core release 1.91 (FC2) - Linux 2.6.5-1.326
> Any ideas of any kind in this vein would be greatly appreciated at this point...
If it's any use I've seen something similar, but always when an
X-terminal has been scrolling fast in the reverse direction, such as
when hitting the page up key, and when using very big screen resolutions
such as 1600x1200.
Robert Billing, Tanglewood,
01344-772849 64, Pinehill Road,
http://www.tnglwood.demon.co.uk/ Berks, RG45 7JR
Since the version shift in redhat-menus gnome lost it's More submenus.
I'm pretty positive that most users will consider this a bug, so I
attached here a patch for redhat-menus.
Also I've attached one for redhat-lsb because it simply won't install
(anaconda overrides this) kill was moved from /usr/bin to /bin, and the
spec wasn't updated.
Razvan Corneliu C.R. "d3vi1" VILT <razvan.vilt(a)linux360.ro>
Digital Vision - linux360 - Vision Project Maintainer