Re: Rambling apt-get ideas
Anyway, what does apt-cache not do that you want to have happen?
Re: Linux Progress Patch for Debian available!
On Sun, Dec 31, 2000 at 02:42:25PM -0800, Joey Hess wrote: > Bernd Eckenfels wrote: > > AFAIK there is a problem with this patch since some of the copyright > > messages of the drivers are not displayed anymore. since some of them > > require the Copyright announcement, this is a violation of the license. As > > far as I know that was the reason for not putting that patch into the > > kernel, long ago. > > Can you show me an example of such a license? And not to be pedantic or anything, but how are these Copyright announcements handled on a machine that boots headless? I would think that would be just the same violation of the license. -- Ferret Who recalls a cddb access program designed for blind people where cddb.com DENIED a certification because the program couldn't display a graphical logo where the blind people could see it.
Using normalize from another program [was Re: ITP: normalize]
On Wed, Jan 03, 2001 at 01:47:00PM -0200, Eduardo Marcel Macan wrote: > Normalize is a nice program that adjusts volume levels of a bunch > of wav files, it is very useful when you want to make audio CDs from > audio recorded from multiple sources for an example. sox provides volume > level adjusting , but normalize presents us with an easier to use interface, > and can adjust levels based on the average level of a set of wav files > among other useful characteristics. > > .deb is ready and if no one objects I'll upload it as soon as I can. > > normalize home page is at: > > http://www.cs.columbia.edu/~cvaill/normalize/ Hey, this looks spiffy. I have something of a usage question though, in regards to the 'gender' (distributed ripper/encoder) program I'm scripting. I'd LIKE to add audio normalisation as an option, but since ripping and encoding tasks happen concurrently and asynchronously (but with file locking) I'm not at all sure how to handle a sane normalisation default, or even if there IS such a beast. -- Ferret
Re: Using normalize from another program [was Re: ITP: normalize]
On Wed, Jan 03, 2001 at 05:33:41PM -0200, Eduardo Marcel Macan wrote: > On Wed, Jan 03, 2001 at 10:59:18AM -0800, [EMAIL PROTECTED] wrote: > > Hey, this looks spiffy. I have something of a usage question though, in > > regards to the 'gender' (distributed ripper/encoder) program I'm > > scripting. I'd LIKE to add audio normalisation as an option, but since > > ripping and encoding tasks happen concurrently and asynchronously (but > > with file locking) I'm not at all sure how to handle a sane > > normalisation default, or even if there IS such a beast. > > Normalization has to take into account the maximum amplitude each > wave reaches before scaling each value down or up to the desired level. > > normalize computes the power of each small block of the the sound file > in RMS (Richard Matthew Stallmans , sorry, I couldn't resist :) :) :) ) > looking for the highest value so all blocks can be proportionally scaled. > > So, there is no way to have normalization ocurring concurrently > to acquisition of the sound and encoding. You'll have to record everything > first, then normalize everything and then encode the normalized file. > It is not possible to do normalization through a pipe, for an > example. Hehe. 'everything' is a slippery word here. I grok you to mean 'the whole track' and not 'every possible track to be recorded'. ;) Anyway, I could still have normalisation and acquisition processes running concurrently; just not on the same track. > You can normalize each file to a predefined aplitude value so you can > do it once each file was "ripped" instead of doing normalization in batch > mode. The author of normalize chose from his experience 0.25 dB to be a > good power default. > > I use this default to record my CDs (made out of my own midi files and > mods mostly) and I am glad with it. I'll do this then. I read his examples and was a bit confused how to apply them to my project. Thanks. -- Ferret
Re: Important Note On Source-Only Uploads
On Fri, Jan 05, 2001 at 10:10:53AM +0100, Martin Bialasinski wrote: > * Anthony Towns wrote: > > > Actually it's weird. Pine seems to be surviving for some reason. I > > don't know why. :-/ > > It is what my users learned on some other AIX maschine at my > university. It is the first mailer I learned and used. > > Pine is extremely easy to use and understand. I don't know any other > mailer like it. Last time I tried pine mode in mutt, it didn't come > near the real thing. > > As long as there is no other mailer like it, I don't want to force a > change on these users. I wonder what happened to mana.. Yeah, I used pine since forever.. but it was getting to the point where one pine process would consume over 200MB memory just opening a single 40MB mailbox, and crash and/or corrupt parts of my machine. -- Ferret
Re: Linux Progress Patch for Debian available!
On Mon, Jan 08, 2001 at 10:16:42AM +0100, Florian Hinzmann wrote: > > On 03-Jan-2001 Paul Hedderly wrote: > > On Mon, Jan 01, 2001 at 11:37:17AM -0800, [EMAIL PROTECTED] wrote: > > >> Who recalls a cddb access program designed for blind people where > >> cddb.com DENIED a certification because the program couldn't display a > >> graphical logo where the blind people could see it. > > > > Presumably no blind person is allowed to use any cddb.com certified > > program then. Hmm :O) > > Thats one of the reasons there is http://freedb.org/ now. Yah.. i seem to recall filing a bug against abcde for the same reason. So.. Specifically what parts of the kernel fail this patch? We had a discussion regarding other 'borderline' compliant parts of the kernel a few weeks ago, too. (regarding the Plex86 ITP and firmware) -- Ferret
Re: Caching Proxy for apt-get via http?
On Sun, May 06, 2001 at 03:05:12PM +0100, Andrew Suffield wrote: > On Sun, May 06, 2001 at 07:54:17AM +0200, Harald Dunkel wrote: > > Does anybody out there know what is the problem here? Maybe its > > the failure of Apache. What are your suggestions for running a > > cache for apt-get? > > Umm... how about "apt-proxy"? If you don't mind running (and debugging) experimental code.. Has a particularly hard time with round-robin mirrors not being in-sync, or (I think) occationally a mirror not supporting rsync access at all. Also has trouble with over-returning to the client. FE will return 5MB of a 200k deb.. And it requires rsync access to the repository. Despite all this, I did find it working a bit better on my dialup connection than squid was. Oh yeah, you'll want to give it a big cache, too. It doesn't seem to be able to clean its own cache properly. -- Ferret
