> Date: Fri, 04 Feb 2005 18:10:32 -0800
> From: Ryan Gammon <rgammon(a)real.com>
> Message-ID: <42042B18.2090207(a)real.com>
Sorry for the lack of threading ... I get message digests.
> Hi guys,
> I've been catching up on my mailing list reading on fedora, helix, and
> general sound server interaction, and saw a couple threads of interest
> from late last year.
> I'm curious to know what the current fedora thinking is on software
> mixing & sharing sound hardware, particularly with sound devices that
> don't have any hardware mixing support.
As a regular user who is stuck with one of those onboard soundcards that
is quite capable *except* for the seeming lack of hardware mixing, I
would be extremely happy to see someone focusing on this. A complication
that I have is the need to run programs that are OSS only (Teamspeak2
and Quake3 to be specific) and the OSS emulation via ALSA seems to add
an extra wrinkle into getting any sort of software mixing (particularly
sound capture) working properly. I have played around with
arts/esound/.asound with no success.
One project that I noticed recently is oss2jack that I thought might
solve my problem by plugging OSS directly into JACK instead of the OSS
emulation in ALSA. I would hate to have to wedge this stuff into my
configuration every single kernel update though (I have recently given
up running on the GATOS treadmill to keep my ATI AIW TV tuner
working ... I am crossing my fingers to see some of that stuff natively
in Xorg) and I sense that the chance of any of these thing making it
upstream are slim especially without someone knowledgeable of such
things (read "not me") pushing it along.
Anyways, JACK seems to list ALSA as a supportee. Maybe the OSS emulation
in ALSA could be modified to run more smoothly with JACK/dmix/etc. and
let ALSA figure out if there is a hardware mixer available or not.
Hoping that OSS applications go away is not the way to go.
Linux falling on its face due to sound hardware contention is one of the
last embarrassments left when I am trying to sell Linux as a true
Windows replacement to friends and family.
Firefox is not starting properly for me since updating (almost
completely - control-center has a conflict so wont install) to the
current development rpms
When I try to run firefox I get nothing on the screen.
A look at 'ps ax | grep firefox' shows:
[rodd@trevally ~]$ ps ax | grep firefox
3394 ? S 0:00 /bin/sh /usr/lib/firefox-1.0/firefox -UILocale en-US
3415 ? S 0:00 /bin/sh /usr/lib/firefox-1.0/run-mozilla.sh /usr/lib/firefox-1.0/firefox-bin -UILocale en-US
3420 ? Sl 0:00 /usr/lib/firefox-1.0/firefox-bin -UILocale en-US
3523 pts/2 R+ 0:00 grep firefox
I can kill these processes, but it doesn't help.
the new kernels have xen configs (nice :), but rpmbuild -bp --target
noarch breaks on FC2. Since there are noarch builds published for FC2,
I guess that maybe something is different in Dave's build environment?
Error is below.
+ cp .config configs/kernel-2.6.10-i686-smp.config
+ mv kernel-2.6.10-i686-xen0.config .config
++ echo kernel-2.6.10-i686-xen0.config
++ cut -d- -f3
++ cut -d. -f1
++ sed -e s/i.86/i386/ -e s/s390x/s390/ -e s/ppc64.series/ppc64/
+ make ARCH=i386 nonint_oldconfig
.config:39: trying to assign nonexistent symbol PREEMPT_BKL
.config:62: trying to assign nonexistent symbol PCIEPORTBUS
.config:94: trying to assign nonexistent symbol INFINIBAND
.config:95: trying to assign nonexistent symbol INFINIBAND_MTHCA
.config:96: trying to assign nonexistent symbol INFINIBAND_MTHCA_SSE_DOORBELL
.config:97: trying to assign nonexistent symbol INFINIBAND_MTHCA_DEBUG
.config:98: trying to assign nonexistent symbol INFINIBAND_IPOIB
.config:99: trying to assign nonexistent symbol INFINIBAND_IPOIB_DEBUG
.config:134: trying to assign nonexistent symbol MTD_BLOCK2MTD
.config:203: trying to assign nonexistent symbol MTD_NAND_NANDSIM
.config:208: trying to assign nonexistent symbol MTD_REDBOOT_DIRECTORY_BLOCK
.config:210: trying to assign nonexistent symbol MTD_XIP
.config:241: trying to assign nonexistent symbol ACPI_CONTAINER
.config:381: trying to assign nonexistent symbol SCSI_ISCSI_ATTRS
.config:750: trying to assign nonexistent symbol BRIDGE_EBT_ULOG
.config:808: trying to assign nonexistent symbol CLS_U32_MARK
.config:4601: trying to assign nonexistent symbol XEN_BLKDEV_BACKEND
.config:4602: trying to assign nonexistent symbol XEN_NETDEV_BACKEND
.config:4603: trying to assign nonexistent symbol XEN_BLKDEV_FRONTEND
.config:4604: trying to assign nonexistent symbol XEN_NETDEV_FRONTEND
.config:4605: trying to assign nonexistent symbol XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER
make: *** [nonint_oldconfig] Error 14
make: *** [nonint_oldconfig] Error 2
Axel.Thimm at ATrpms.net
I just received this email about udftools :
At least the listinfo/mailman page says that's what your name is. ;-) I'm
a list subscriber, but I am also interested in seeing udftools get
for Fedora. As of kernel version 2.6.10 there is a new module called
which supports packet writing(udf) to CD-RW media. I believe that is what
Jon Roland is referring to in his post:
As it happens I have been trying to learn how to build rpms from scratch
this seemed(at first glance) to be a simple enough one to start with.
I had already built the package from the source tarball with the patch from
Peter Osterlund's website:
I decided to try and package it myself. The attached files contain the
results of the first build that I've gotten to run to completion. It
been tested yet and I'm sure the spec file needs work. I cobbled it(the
file) together from an old Red Hat contrib package and a current Mandrake
package. But, if you think others might be interested, please pass it
So I was wondering... should udftools go into Extras, or into Core? Since
support for packet writing has been included in the kernel, I'd favour Core
(and this is why I'm posting here).
Oh, and I've even found some old udftools packages made by someone @rh :
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3
Load : 0.12 0.42 0.45
> > Indeed. I have a single Opteron 3400 that is cranking a measured 1.65
> > times better performance than my previous machine on doclifter, my
> > monster Python app -- which doesn't sound impressive until you
> > consider that the previous machine was a 2-processor SMP with 1.8GHz
> > Athlons. So my real-world throughput is as good or (allowing for
> > Amdahl's Law inefficiencies) better than what I'd get from a 6 GHz
> > Athlon, if such a thing existed.
> I was under the impression that the Python interpreter was serialized
> and thus unable to take good advantage of SMP systems.
> If that's the case, then you'd only be getting one of those 1.8GHz
> processors beating on 'doclifter'... and if that's the case, you'd be
> looking at a 3GHz Althon instead of 6GHz.
Hmm...you're probably mostly right about this. The Python app would get
some gain from background daemons and X traffic migrating to the other
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-----BEGIN PGP SIGNED MESSAGE-----
S Murthy Kambhampaty wrote:
| As discussed previously on this list, Samba RPMs for
| Fedora Core do not include idmap_rid support. This is
| also true for older RedHat distributions. SuSE on the
| other hand, seems to have been patching in idmap_rid
| support since 3.0.5 or so; and with trusted domain
| support, to boot. Harrumph.
| I've been able to rebuild samba srpms on FC2 and
| RedHat 8 by patching the samba distributed rpms, and
| get idmap_rid support which is a lot easier than using
| the xad plugins (no offense to PADL and Luke H., but
| our setup is simple so idmap_rid is all we need). The
| diffs are attached; it would be nice if they could be
| Thanks, Murthy
| PS: It is way cool that mappings produced by RH8, FC2
| and SuSE 9.2 are same, with so little effort, thanks
| for this feature, Samba team.
Murth, If you will send me your spec file patches I'll
get them in for the next Samba release. The attachments
were strippedby mailman (for samba.org at least).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
CC'ing fedora-devel-list because there are some things that need to be
sorted for a possible FC-4/ppc _release_
Now, a list of known issues:
0. this boot.iso + nfs installation system has to go away - so we need
to give anaconda love
1. out of the box video detection - system-config-display needs to be
hacked on to recognise all the common Mac hardware bits out there. We
can't be pushing Xautoconfig or something similar... but we can lean on
it for inspiration if need be
2. anaconda and partitioning - auto partitioning possibly still fails (I
don't think the Apple Bootstrap partition gets created); running
yabootconfig automatically after installation, with an appropriate
initrd and so on needs to happen (we can't depend on users breaking out
into a shell)
3. sound is still relatively broken - dmasound_pmac tends to work, but
is not the default config. system-config-soundcard definitely needs some
work to make it play well with the Macs
4. power management - we need either pmud or pbbuttonsd. The latter has
received no love from most fedora/ppc users, so pmud seems to be the
winner, I'd guess. We need this included in Core (building only for ppc,
and possibly later ppc64). We know yellow dog add some nice patches for
disabling the touchpad in pmud - I guess the package maintainer can be
free to include such patches at will if need be
5. updates - we can't have david woodhouse (dwmw2) grabbing packages
from the RH build system and having to host them at ftp.linux.org.uk -
we need a better mechanism. i.e. the normal way package updates go out,
can the ppc and ppc64 packages go out with them too? This might involve
some policy change at Red Hat, so can someone in the know, speak up?
6. back to the topic of power management; there are some patches out
there that help G4 iBooks and newer powerbooks sleep (and wake up).
They're not in the upstream kernel.org kernel, but with good benh
approval (!), we might consider patching the kernel to make it more
useful. dwmw2 currently builds kernels with these patches enabled
7. we'll be upfront about modems and Airport Extreme probably never
working for free. Modems have drivers at linuxant (though they still
might be flaky with our stack size in the kernel), but the Airport
Extreme stuff is probably a no go (not yet at least)
8. 64-bit support. I personally don't have a G5 or anything ppc64, but I
know that dwmw2 has one sitting at work, as probably does nasrat. We
need more 64-bit testing, and making sure that anaconda boots on them
too (if not we need more anaconda hacking). There have been reports that
things were (or are still) broken on a 64-bit arch
9. PegasosPPC (Genesi) makers of PPC boards have thought of getting
FC4/ppc to work on their machines. I'll be taking a look at this, though
does anyone else have such machines around?
10. spanking MiniMac support?
I guess this is a list of outstanding issues that we need to fix before
Fedora Core 4 gets a PPC release. If I missed anything glaring, do add
on the the thread
Otherwise, lets get some C and Python hackers hacking on the packages
above, and making things "just work" for FC/ppc. PPC specific discussion
can take place at fedora-ppc(a)lists.infradead.org
Colin Charles, byte(a)aeon.com.my
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi