Re: Why can't i access /dev/dsp or /dev/snd on my XO
Ivo Emanuel Gonçalves ([EMAIL PROTECTED]) said: > On 1/21/08, Dan Williams <[EMAIL PROTECTED]> wrote: > > Except that it's completely insane to try to diverge from the upstream > > kernel and userland here. > > Uh? You are supposed to costumize the kernel as you feel like it. > Freedom of choice and all. Sure. You could boot the kernel with an entirely separate sound stack, storage stack, networking stack, etc. Doesn't necessarily mean it's a good idea. > Also, if it may bother you, why not bring > the issue up to Mr Torvalds? You're the one with an issue with the status quo - I suggest *you* bring the issue of OSS4 up to the upstream kernel. Bill ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why can't i access /dev/dsp or /dev/snd on my XO
Albert Cahalan ([EMAIL PROTECTED]) said: > You can read Hannu's take on the matter in his blog. This > entry is particularly informative, but note that the code > has since been released under the GPL. > http://4front-tech.com/hannublog/?p=5 It must be informative and unbiased. After all, he refers to people who disagree with him as Borgs. Frankly, if you want to ship ALSA's OSS emulation, it's just a few modules. But swapping out the entire driver stack to something that's not used anywhere else at the moment just seems silly. Bill ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why can't i access /dev/dsp or /dev/snd on my XO
Ivo Emanuel Gonçalves ([EMAIL PROTECTED]) said: > As far as I understand this is due to the use of ALSA without OSS > emulation. It's also what affects one of the three Speex bugs > affecting the XO, as the CLI tool speexdec is unable to use /dev/dsp. > > For the sake of improving the state of audio in the XO; I'd really > like to put to vote the idea of replacing ALSA with OSS 4. I can't imagine why intentionally divorcing from the upstream sound model to a driver stack that is never going to the upstream kernel would be a *good* thing. Bill ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: PATCH: add --loginpause to mingetty
Lubomir Kundrak ([EMAIL PROTECTED]) said: > > I'm committing these changes to the OLPC-2 branch of mingetty in > > Fedora CVS. Please, let me know you'd like to merge them or > > something similar. > > Such things are definitely better upstreamed if possible. Have you tried > contacting upstream? Florian is upstream, IIRC. Bill ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
Jake Beard ([EMAIL PROTECTED]) said: > Hopefully, later this year we'll see a completely open Java, and then see > Java on the XO. > Flash is terrible. If it were possible, I'd prefer to see an all-Java > solution. That being said, in my experience both with closed and open Java implementations, I wouldn't expect a huge speed improvement on the OLPC from switching from Flash to Java. Bill ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: /lib/lsb/init-functions vs. /etc/init.d/functions in init scripts?
Bernardo Innocenti ([EMAIL PROTECTED]) said: > On 08/28/2007 01:58 PM, Bill Nottingham wrote: > > Bernardo Innocenti ([EMAIL PROTECTED]) said: > >> If there are no resources to do it, I hereby volunteer > >> to do this work in due time, provided there's interest > >> from the current redhat-lsb maintainers to merge my > >> changes back. > > > > Taking patches, although I'd start with the stuff in /etc/init.d/functions. > > Agreed. My idea was to start by moving only the parts > of code that LSB advertises from /etc/init.d/functions > to /lib/lsb/init-functions. Would that make sense? Not unless lsb/init-functions moves to someplace that doesn't require the whole mess of the lsb stack; we don't want init scripts bringing in the entirety of openssl, X, cron, pax, shadow-utils, etc. Bill ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: /lib/lsb/init-functions vs. /etc/init.d/functions in init scripts?
Bernardo Innocenti ([EMAIL PROTECTED]) said: > If there are no resources to do it, I hereby volunteer > to do this work in due time, provided there's interest > from the current redhat-lsb maintainers to merge my > changes back. Taking patches, although I'd start with the stuff in /etc/init.d/functions. Bill ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Splitting the ncurses RPM
Miroslav Lichvar ([EMAIL PROTECTED]) said: > > For sanity's sake on upgrades, leaving the libraries in the same > > package name (multilib) would be best. > > I'm confused, do you want to keep the libraries in ncurses package? (This has nothing to to with OLPC, and everything to do with the distro) If the libraries move to a different package, we end up with ncurses-devel/ ncurses-libs being multilib, instead of ncurses-devel/ncurses as we have currently. This causes problems for upgrades with getting a no-longer-multilib ncurses package off the system for the secondary arch. So, if possible, keeping the libraries in the 'same' package as it was previously is preferred. Bill ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Splitting the ncurses RPM
Miroslav Lichvar ([EMAIL PROTECTED]) said: > Ok. Maybe I'd use a bit different naming instead: > > ncurses-bin: bin/* > ncurses-base: lib*.so.* /etc/terminfo /lib/terminfo, some of > /usr/share/terminfo > ncurses-terminfo: rest of /usr/share/terminfo > ncurses: requires: -bin -base -terminfo > > How does this sound? For sanity's sake on upgrades, leaving the libraries in the same package name (multilib) would be best. Bill ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
