[Debconf-video] LAC 2008: bandwidth to burn and volunteers needed
The 6th annual Linux Audio Conference is taking place in Cologne, Germany, Feb 28th to March 2nd, 2008. As with each previous year this year's conference will be streamed live over the internet in ogg theora via icecast. The stream server is up at: http://lac2008.khm.de:8000/ There is nothing to see at the moment, but keep checking over the coming days as we hope to have a test stream up soon. This year we are in the unique situation of having a Gigabit link donated by CITIZENMEDIA: http://www.ist-citizenmedia.org/ They have asked us to use up as much of their bandwidth as we can so they can see how well the link performs. This year the core team, Joern Nettingsmeier and myself, are recruiting volunteers to spread the workload. To that end we have set up a mailing list and irc channel to coordinate our efforts. We will also have a wiki shortly. If you will be coming to Cologne for the conference please consider signing up to help. If you are not coming, please enjoy the fruits of our labors by watching the streams and participating via irc. stream team mailing list: http://zhevny.com/mailman/listinfo/lac-streams general conference chat: #lac2008 on irc.freenode.net stream team tech talk:#lac2008-tech on irc.freenode.net Thanks, Eric Rz. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Debconf-video mailing list Debconf-video@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-video
Re: [LAD] portmidi and alsa
On Fri, Nov 23, 2007 at 02:40:29PM +0100, Clemens Ladisch wrote: Dave Phillips wrote: Clemens Ladisch wrote: Portmidi designed is based on Windows' MME API which doesn't allow applications to create ports visible to other applications. Ah, that's good to know. Is that true for PortAudio also ? Yes (but in the case of audio, the native APIs of all OSs have this dichotomy between devices and applications). Which is why we have jack for applications to create ports visible to other applications? -Eric Rz. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Bug#434839: libvorbisenc2: New upstream version
Package: libvorbisenc2 Version: 1.1.2.dfsg-2 Severity: wishlist Version 1.2.0 is available upstream with some bugfixes and support for playing only the audio portion of multiplexed streams such as video. Release announcement: http://lists.xiph.org/pipermail/vorbis/2007-July/026903.html Download: http://downloads.xiph.org/releases/vorbis/libvorbis-1.2.0.tar.gz Thanks, Eric Rz. PS I wonder if the pkg-xiph maintainers would consider joining forces with the debian-multimedia team? Just a thought ... -edrz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adopting phat
On Mon, Jul 09, 2007 at 11:46:37AM +0200, Free Ekanayaka wrote: Hi Eric, svn-inject -o package.dsc svn+ssh://[EMAIL PROTECTED]/svn/demudi (you will need the svn-buildpackage package installed Doing it like that injected the phat docs and source into /branches/upstream/. From looking at what's in svn for most of the demudi packages, it seems this is not what I want. Most packages have a /branches/upstream/ directory, but they are largely empty. Perhaps what I want is to use --no-branches? I'll go read the svn-buildpackage docs before I mess it up again. I was going to inject the existing packaging for future reference before I start on the new one. Is that worthwhile? Thanks, Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
adopting phat
I see that phat has been orphaned. Since I filed #381026 almost a year ago and I'm (nominally) the upstream maintainer of specimen which requires it, I think I'm going to adopt it. I would like to have the debian-multimedia group as the maintainer. Reading the debian-mentors faq suggest that to do this I should: -retitle #391134 to begin with ITA -package the latest release -close 381026 and 391134 in the changelog -upload somewhere to get a sponsor's approval So, anything missing from that list? Would the debian-multimedia project on alioth be the most appropriate place to put it to get a sponsor? Thanks, Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
should this list have an irc channel?
Does this list currently have a corresponding irc channel? There is an rzr in #debian-multimedia on oftc at the moment, but no one else. There is still a #demudi on freenode which is also sparsely populated (and probably not worth reviving(?)). I'll be in #debian-multimedia on oftc. I don't know anything about registering channels and making them official and all that, though. I've often wanted to be able to just chat about debian audio and video issues. We do a fair bit of that in #debconf-video, but a more specific place to discuss this stuff that didn't also get debconf traffic would be nice, imho. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adopting phat
On Mon, Jul 09, 2007 at 07:12:35PM +0200, Bart Martens wrote: On Mon, 2007-07-09 at 03:24 -0400, Eric Dantan Rzewnicki wrote: I see that phat has been orphaned. Since I filed #381026 almost a year ago and I'm (nominally) the upstream maintainer of specimen which requires it, I think I'm going to adopt it. I would like to have the debian-multimedia group as the maintainer. Reading the debian-mentors faq suggest that to do this I should: -retitle #391134 to begin with ITA -package the latest release -close 381026 and 391134 in the changelog -upload somewhere to get a sponsor's approval Where did you upload it? I did not yet upload anywhere. This will be my first attempt at packaging for debian (I have done some packaging for my own use and for local use at my last job). My mail was to ask for advice and make sure I knew where I was going before I started. When I do, I will upload to alioth demudi project as I believe in team maintenance. Thanks, Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: should this list have an irc channel?
On Mon, Jul 09, 2007 at 04:13:53AM -0400, Eric Dantan Rzewnicki wrote: Does this list currently have a corresponding irc channel? There is an rzr in #debian-multimedia on oftc at the moment, but no one else. There is still a #demudi on freenode which is also sparsely populated (and probably not worth reviving(?)). I'll be in #debian-multimedia on oftc. I don't know anything about registering channels and making them official and all that, though. I've often wanted to be able to just chat about debian audio and video issues. We do a fair bit of that in #debconf-video, but a more specific place to discuss this stuff that didn't also get debconf traffic would be nice, imho. Thanks to Ganneff and holger I've figured out the basics of registering the channel. Currently I'm the only one with op privs. I don't care to be op and as soon as anyone else who is registered on oftc joins I'll spread oppishness around. Can a note about the channel be added to the alioth page and perhaps somewhere in the list info? Thanks, Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Low-latency kernel
On Sat, Jun 23, 2007 at 05:01:00PM +0200, Lars Luthman wrote: Hi Arnout, |--== Arnout Engelen writes: AE Hi! AE One of the first things anyone doing multimedia stuff with Debian is AE going to want is a kernel that's configured for low latency. AE What is currently the recommended way of configuring/installing such a AE kernel? Might be a good idea to put (a link to) some documentation AE about this somewhere on http://wiki.debian.org/DebianMultimedia AE Ubuntu has a 'linux-image-lowlatency' package providing a readily AE configured and built kernel suitable for multimedia work. As far as I know the 'linux-image-lowlatency' kernel has not been patched with the realtime-preemption patch from Ingo Molnar. AE I haven't AE checked, but I expect 64 Studio and Studio To Go! to have done similar AE work. It might be worthwhile to compare notes and perhaps provide such AE a package for Debian also. Both these distros come with a realtime-patched kernel, for 64 Studio the package is available here: deb http://apt.64studio.com/64studio/testing 64studio main http://apt.64studio.com/64studio/testing/pool/main/l/linux-2.6/ Is there any particular reason (other than lack of time and manpower) for not having an RT-patched kernel package in standard Debian unstable? Would it cause any problems for other packages? This was discussed a while back. I think Free basically said, the security team will not support such a kernel themselves, but otherwise is not opposed. It is basically a person-power issue as I understand it. Some few people who have the ability and time to keep up with kernel security issues and provided patched rt kernels in a timely manner are the basic missing pieces. I'll try to find the thread in the archives. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429937: [EMAIL PROTECTED]: Re: ffmpeg2theora large file support]
- Forwarded message from [EMAIL PROTECTED] - Date: Thu, 21 Jun 2007 22:31:39 +0200 From: [EMAIL PROTECTED] Subject: Re: ffmpeg2theora large file support To: Eric Dantan Rzewnicki [EMAIL PROTECTED] X-Mailer: Apple Mail (2.752.3) Hi, compiling from svn this should work, i added AC_SYS_LARGEFILE to configure.ac some time ago, will check again in the next days one i get some larger file to test... j On Jun 21, 2007, at 13:52:29, Eric Dantan Rzewnicki wrote: We ran into an issue with files encoded from dv getting truncated at 2GB. EXTRA=-D_FILE_OFFSET_BITS=64 -I$(prefix)/include in Makefile.am doesn't seem to make it to the compiler. -Eric Rz. (edrz on freenode) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-team] Minutes 20070617
On Sun, Jun 17, 2007 at 08:16:05PM +0100, José Miguel Parrella Romero wrote: Mark Brown wrote: - Hacklab 1 circuit breaker tripped today. A breaker also tripped in HL2 today. The one in the mini-bar, at the left, behind a machine in the table. One of those multi-outlets was crackling and it was heating up -- people should be advised not to stress the power outlets and avoid cascading multi-outlets. Do we (video-team) have the authority to not allow people to plug in at the desk in Talk Room1? Many people want to charge their cell phones and laptops and whatnot off the power bars we're using for the audio mixer, selma (the dvswitch machine) a camera and our own laptops. I've been concerned about it, but unsure of being authoritarian about saying no. Not to mention that someone unplugged me yesterday without me knowing it till my battery died. -Eric Rz. ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-video] Tips and tricks for the speaker camera in UpperTalkRoom
I've edited together Herman's mails: As I looked at one of the freshly encoded high-resolution videos (079_Free_software_in_the_commercial_environment.ogg) I noticed two problems: 1) Over-exposure and 2) noise. 1) Over-exposure is best checked with the zebra pattern, which is turned on with a switch on the back of the camera, near the top. When the zebra function is on, areas which are nearly white will appear with a flickering zebra pattern in the viewfinder. If a large part of the speaker's face is covered by the zebra pattern, gain should be switched down/off, and the iris adjusted, as needed. A quick and dirty way to adjust the image is to turn the iris down (metal knob on the front) until the zebra disappears, then turn it gently up until a few areas become zebraed. Things that are supposed to look bright white should be zebra-patterned. 2) If the final encoded video has visible noise, gain must have been used. The low dB setting gives only very subtle noise, which the encoder may suppress completely. If the noise is obvious, 18dB gain (high) was probably used. Instead of gain, open the iris (lowest number/largest opening is f:1.6) or use 1/25s shutter speed: Shutter speed, f-stop (iris) and gain amount are all shown in the viewfinder. If they are not, they are on auto! (possible exception: the gain) a) Turn gain off. Is the picture too dark? The gain is a flip switch on the left side, next to the white balance switch. It has three positions (from top to bottom): High, low and off. b) Open the iris (shiny metal knob) wide open. Still too dark? c) Increase the shutter speed (default 1/50s) to 1/25s. The shutter is set with the menu wheel at the back, near the bottom. If the shutter speed is 1/25s, you'll see 25 in the viewfinder. d) Set the gain to 9dB, if the above was not enough. e) Last resort(!): Use 18dB. Only required in pretty dark environments. You can also use even longer shutter speeds, with flickering and blurry results. At 1/6s, the camera sees more than your eyes, in full colour! With just one of the three exposure settings (shutter, iris, gain) set to auto, manual adjustments will be countered by the automatic control. This is not what you want. The auto/manual toggle buttons for shutter speed, iris, gain and white balance are near the bottom on the left side. ___ Debconf-video mailing list Debconf-video@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-video
Re: [Debconf-team] Inventory, 1st round
On Thu, Jun 14, 2007 at 09:12:09PM +0100, Felipe Augusto van de Wiel (faw) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/14/2007 05:49 PM, Eric Dantan Rzewnicki wrote: On Thu, Jun 14, 2007 at 06:40:51PM +0200, Herman Robak wrote: [...] Should I ask the videoteam to upgrade their hardware list to an inventory? That would be a good idea also considering my possibly lost equipment. Sorry. What possibly lost equipment we are talking about? Sorry for being terse. There was a bunch of stuff of mine previously in the videoteam list. It is currently in limbo due to a airline snafu with my baggage. I will hopefully have my stuff tomorrow around 9am. -Eric Rz. ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] Inventory, 1st round
On Thu, Jun 14, 2007 at 06:40:51PM +0200, Herman Robak wrote: On Thu, 14 Jun 2007 18:25:59 +0200, Felipe Augusto van de Wiel (faw) [EMAIL PROTECTED] wrote: On 06/13/2007 10:46 AM, Herman Robak wrote: On Mon, 11 Jun 2007 19:29:09 +0200, Herman Robak [EMAIL PROTECTED] wrote: I'm not editing the inventory myself. The purpose of the inventory is to document what you have registered and labeled, right? Yes! But you could have edit it. Basically, if it is already inventoried by VideoTeam, it is safe. :-) I'm using VideoTeam Hardware Page as part of the inventory page. Well... I wrote the info about my cameras, most of it before it was sent. So the videoteam's hardware page shows what they are _supposed to get_, not what they _actually have in their possession_. Should I ask the videoteam to upgrade their hardware list to an inventory? That would be a good idea also considering my possibly lost equipment. -Eric Rz. ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: jack-audio-connection-kit_0.103.0-1_amd64.changes is NEW
Yay! On Thu, Apr 12, 2007 at 08:47:05AM +, Debian Installer wrote: jack-audio-connection-kit_0.103.0-1.diff.gz to pool/main/j/jack-audio-connection-kit/jack-audio-connection-kit_0.103.0-1.diff.gz jack-audio-connection-kit_0.103.0-1.dsc snip Changes: jack-audio-connection-kit (0.103.0-1) unstable; urgency=low . * New upstream release * Drop patches 04_configure_in_jack_version and 02_release-in-libjack-name as suggested by the upstream developers, they will take are of possible ABI changes and add the relevant runtime checks * Drop patch 11_configure.ac, fixed the lib64 path in debian/rules * Drop build-dependency on automake * Rename the library and the headers binary packages to reflect the fact that they are not anymore version-specific, add dummy binary package libjack0.100.0 to provide an upgrade path * Bug fix: libjack0.100.0-0: 04_configure_in_jack_version.patch makes add-on installation complicated, thanks to Mario Lang (Closes: #353680). * Remove rpath from the binary programs using chrpath * Enabled SSE (see http://ardour.org/node/820) snip You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. Does that bit mean the changelog should have testing instead of unstable? -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
On Thu, Apr 12, 2007 at 10:33:32PM +0200, Ismael Valladolid Torres wrote: Eric Dantan Rzewnicki escribe: /etc/security/limits.conf needs to be set up as well. It's a simple step, but I guess it would be good if users didn't have to ask about it. A multimedia dedicated distro should ship /etc/security/limits.conf configured for realtime but not a generic distro. Letting all process from a user in the group audio getting realtime could pose a security problem in a server setup. Sure, but some sort of audio-workstation meta-package could perhaps include a debconf question that sets this up based on user input or something. It would of course not be something installed by default on all systems whether asked for or not. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: [Jackit-devel] [Freebob-devel] freebob and Ubuntu 6.10]
On Wed, Apr 11, 2007 at 02:45:25PM +0200, Free Ekanayaka wrote: |--== Eric Dantan Rzewnicki writes: EDR The problem is fixed in debian experimental. That won't help most users EDR until lenny gets rolling. Since etch was released on Sunday, a EDR transition will likely be planned within the next, hmm ... I don't know, EDR say maybe 1/2 year or so(?) to get all of the jack dependent apps EDR rebuilt with a sanely named .so dependency. The new coming-soon jack package will fix the issue. However it will take a while before all jack-dependant packages get rebuild (and as I said, a rebuild is not really necessary, as the new jack package is backward compatible). EDR My hope is that we (debian developers and developer-wannabes, like me) EDR can also provide backports for etch that make this less of a PITA for EDR users. That would be a Very Good Thing! I think it should not be too difficult to achieve that, we would probably need to set some auto-builders that fetch source packages from sid and rebuild them for etch. Can this be done at backports.org? -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
On Wed, Apr 11, 2007 at 02:37:53AM +0200, Free Ekanayaka wrote: If my interpretation is correct, my question is, Marco according to your experience is the installation of a multimedia/desktop kernel on a plain Debian (or Linux) distribution enough to fill the responsiveness gap? /etc/security/limits.conf needs to be set up as well. It's a simple step, but I guess it would be good if users didn't have to ask about it. If the multimedia kernel includes ingo's rt patches, then some script to set IRQ priorities and such, like Rui's rtirq thing, is also needed. I feel like there must be something else, but maybe it's just remnants of historical cruft lingering in my brain from earlier years when this stuff took more effort ... 1) Include in Debian a Multimedia/Desktop Kernel IVT I agree it should also be available an apt-get away nevertheless. This is actually not that straight. I've tried to that myself about one year ago, and the feedback from the debian-kernel folks was really positive, but also clear in the guarantees that the possible multimedia kernel maintainer should offer. I was basically said that if I wanted a multimedia flavour to be added, I also had to be available to provide support for the security updates, both in stable and in testing. This request is pretty reasonable to me, but also quite demanding, and I'm not sure if we, as Debian Multimedia Team, have the forces to keep with such a task. Of how many active developers does the Multimedia Team currently consist? and can we recruit more? Are those handling the alsa packages here? what about xiph-maintainers? are there other groups? maybe the gst maintainers? I don't know for sure, but I feel like there must be many more debian-devs who care about audio and video than those who currently participate in this list. (I intend to begin the new maintainer process this year, but I don't count, yet.) 2) Make Jackd usable out of the box or after the installation of a normal package I've lost the quoting ... so not sure who asked this, but did you mean make it easy to build and use jack from not-yet-debian-packaged release or svn? Removing the .so name mangling as Free has done will help with this. In my somewhat naive understanding, it seems there are 2 complementary approaches to this issue: 1) keeping jack debian packages up to date with jack releases (so fewer users have a need to build their own). 2) providing a clear and easy set of instructions for users who want or need (say for a bug fix affecting them) debs of svn ... perhaps using svn-buildpackage. So users can easily role their own debs that work with all of their installed jack apps. (or maybe somehow debs could be autobuilt somewhere for each jack svn release ... just thinking out loud, not sure if that is practical or not.) IVT I find it usable out of the box... I agree with what Daniel said, the focus of general purpose distribution is different, but I also agree that we can do much better. I think lenny has the potential to provide a perfectly useable multimedia workstation with very little end-user pain. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: [Jackit-devel] [Freebob-devel] freebob and Ubuntu 6.10]
On Wed, Apr 11, 2007 at 03:14:21PM +0200, Free Ekanayaka wrote: |--== Eric Dantan Rzewnicki writes: That would be a Very Good Thing! I think it should not be too difficult to achieve that, we would probably need to set some auto-builders that fetch source packages from sid and rebuild them for etch. EDR Can this be done at backports.org? Yes, sure, but only as a repository, not as auto-builder. So are there official debian autobuilder hosts that could be set to handle this or would it need to be unofficial, privately donatated cpu cycles? (sorry for all the naive questions. I'm just beginning to learn how the debian project functions.) -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: [Jackit-devel] [Freebob-devel] freebob and Ubuntu 6.10]
On Wed, Apr 11, 2007 at 06:37:53PM +0200, Free Ekanayaka wrote: |--== Eric Dantan Rzewnicki writes: EDR On Wed, Apr 11, 2007 at 03:56:58PM +0200, Free Ekanayaka wrote: |--== Eric Dantan Rzewnicki writes: EDR On Wed, Apr 11, 2007 at 03:42:48PM +0200, Free Ekanayaka wrote: To my knowledge the official debian autobuilder work only with packages inside the official debian pool (backports.org is out of the scope), so I would say the latter, but I could be wrong. EDR In that case, I'm willing to donate cycles. Cool! Do you have a always-up server, or would you simply use your home machine? EDR I have 2 always up servers, one at home and one remotely hosted. Which arch is running the remote one? If you are willing to set up and autobuilder on it, I could help. i386. I need to get my taxes finished this week, but can start working on stuff like this probably next week. Probably if I shut down my mail and irc clients I would already have been finished last week ... 8) -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337599: realtime-lsm for default Debian kernel
On Wed, Apr 04, 2007 at 03:49:34PM +0200, Roland Stigge wrote: Hi, with the attached patch, you can use realtime-lsm (realtime capabilities for ordinary users for e.g. JACK applications). Note: This change is only useful for CONFIG_SECURITY_CAPABILITIES=y configurations like the current Debian kernels. As soon as the kernel really supports general stackable LSM, all this should become obsolete. Background: What realtime-lsm currently does is replace the capability_ops of the default security capabilities. This is done by unloading the capability module and loading realtime.ko instead (they can't be used both). This renders an unusable state for Debian kernels with CONFIG_SECURITY_CAPABILITIES=y. The attached patch instead unregisters the current capabilities (only if really necessary, the old approach of trying to register realtime as a secondary module on problems is kept). On realtime.ko unload, the old state is restored. The only potential problem I see is loading realtime.ko, unloading capability.ko and then unloading realtime.ko (which restores capabilities of a module that doesn't exist anymore: capability.ko). Maybe we can guard against that, somehow? But this would be the CONFIG_SECURITY_CAPABILITIES=m case, where we need to get rid of capability.ko before loading realtime.ko anyway. Kind of academical question... So what do you think? The realtime lsm has been deprecated in favor of using rt rlimits. pam in etch supports this for some time now, so what is the point of spending more time and effort on the lsm? -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337599: realtime-lsm for default Debian kernel
On Wed, Apr 04, 2007 at 05:16:11PM +0200, Roland Stigge wrote: Hi Eric, Eric Dantan Rzewnicki wrote: The realtime lsm has been deprecated in favor of using rt rlimits. pam in etch supports this for some time now, so what is the point of spending more time and effort on the lsm? Not knowing it? :) In fact, jackd's README.Debian and the package realtime-lsm suggest that realtime-lsm is the only solution. Sorry, didn't mean to sound pissy. Yes, the jackd docs are likely out of date and should be changed if so. Care to file a bug? There is a newer jackd that Free uploaded to experimental. It's way to late to get it into etch. But, are documentation changes still being accepted? Now that I know it, I can also use limits.conf. Maybe the jackd documentation should be adjusted (and realtime-lsm removed from the archive). There was never anything wrong with the lsm per se, other than that the kernel devs rejected it. Nonetheless, it should go away eventually. I'm not sure about removing it from etch, though ... there could be numerous documentation bugs like the one you've come across. What do others think? -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: realtime-lsm for default Debian kernel
On Wed, Apr 04, 2007 at 05:16:11PM +0200, Roland Stigge wrote: Hi Eric, Eric Dantan Rzewnicki wrote: The realtime lsm has been deprecated in favor of using rt rlimits. pam in etch supports this for some time now, so what is the point of spending more time and effort on the lsm? Not knowing it? :) In fact, jackd's README.Debian and the package realtime-lsm suggest that realtime-lsm is the only solution. Sorry, didn't mean to sound pissy. Yes, the jackd docs are likely out of date and should be changed if so. Care to file a bug? There is a newer jackd that Free uploaded to experimental. It's way to late to get it into etch. But, are documentation changes still being accepted? Now that I know it, I can also use limits.conf. Maybe the jackd documentation should be adjusted (and realtime-lsm removed from the archive). There was never anything wrong with the lsm per se, other than that the kernel devs rejected it. Nonetheless, it should go away eventually. I'm not sure about removing it from etch, though ... there could be numerous documentation bugs like the one you've come across. What do others think? -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: realtime-lsm for default Debian kernel
On Wed, Apr 04, 2007 at 06:23:35PM +0200, Free Ekanayaka wrote: |--== Eric Dantan Rzewnicki writes: EDR There is a newer jackd that Free uploaded to experimental. It's way to EDR late to get it into etch. But, are documentation changes still being EDR accepted? Do you mean accepted in etch? I think it would be hard to get another jackd revision into etch at this stage, mainly because this is not a release critical bug. Yes, I meant would a documentation change still be accepted for etch. I didn't really think so. But I'll be glad to update the documentation in the next upload of the jackd package, which will happen after etch gets released. That would be good. Thanks, Free. Btw, I'm sorry I was too busy with the streaming at LAC to get a chance to talk to you. I had meant to, but things just got crazy. Any chance you'll be attending debconf? -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debconf7
I'm going to be at debconf helping with the video team. Will there be enough people from this list there to warrant setting up a multimedia bof or working group session? Time permitting, I would like to meet with interested persons to discuss goals for lenny. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[linux-audio-dev] Linux Audio Conference 2007 live streams
The Linux Audio Conference takes place this week 22-25 March, 2007. As in past years LAC2007 will be streamed live in ogg vorbis and theora via icecast. If you would like to watch or listen to the streams please check out the conference wiki streaming page: http://www.medienwissenschaft.hu-berlin.de/lawici/index.php/Live_Streaming Information on the conference itself, including talks, abstracts, schedule and procedings: http://www.kgw.tu-berlin.de/~lac2007/index.shtml -LAC Stream Team
Re: audio recorder on etch?
On Mon, Mar 19, 2007 at 10:54:03AM +0100, Johannes Wiedersich wrote: Scheduling an audio recording with sound-recorder failed on my etch box. Only about the first 3 hours were recorded, resulting in a file just 2.0 GB large. (This was a recording of an opera production, so it is difficult / impossible to predict suitable breaks in order to record smaller chunks.) I cannot find any hint in the documentation to sound-recorder claiming a limit on file size / maximum recording time. I use ext3 and routinely record videos of larger size than 2.0 GB. Is this a bug in sound recorder? Are there any (better) command line tools available for recording audio, that allow for longer recordings? Thanks for any suggestions! regular wav files have a 2GB limit. If you want to record longer than this you need to use a program that can record to wav64. 2 that I know that can do this are timemachine and ecasound. I'm sure there are others. ecasound is a commandline app and is suitable for running from cron. timemachine, I think, can also be run without its gui. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [linux-audio-dev] List migration to linuxaudio.org : remaining issues.
On Thu, Mar 01, 2007 at 05:41:49PM +0100, Robin Gareus wrote: he might be right. a random bot is more likely to spam [EMAIL PROTECTED] than [EMAIL PROTECTED] a compromise woud be la-user, la-dev , la-ann - or [EMAIL PROTECTED] (mailing-list), etc. (but that's not catchy enough) or lad, lau, laa as many of us tend to refer to them colloquially. -Eric Rz.
Re: [linux-audio-dev] audiogui
On Tue, Feb 27, 2007 at 09:09:18AM +0100, Leonard Ritter wrote: On Tue, 2007-02-27 at 11:12 +1100, Loki Davison wrote: well. when in finetuning mode, the slider obstructs other gui elements. I'm hoping to some day, maybe later this year, find a way to make fansliders translucent ... besides that it doesn't even look good. it's scary pointy-edged stuff. and less scary, pointy-edged. Unless someone else gets to it first, of course. These two aspects of the fansliders have always bothered me a bit, but I still prefer them to knobs. -Eric Rz.
Re: [linux-audio-user] Re: [linux-audio-dev] Hunt for old list archives.
On Thu, Feb 22, 2007 at 10:13:26AM -0500, Paul Winkler wrote: On Thu, Feb 22, 2007 at 07:44:46AM -0500, Ivica Ico Bukvic wrote: As far as I know, there are only the 21 messages from 1998 available anywhere. As for 1999, the archives present 2 copies of the same 801 mesages from May 1999 through 07 March 2000: http://lalists.stanford.edu/lad/1999/05/ http://lalists.stanford.edu/lad/2000/19991108-0307/ This is sort of explained in this thread: http://lalists.stanford.edu/lad/2000/Mar/0001.html Kai recreated the archive using his mbox starting from the day he joined around June 1999. The messages from before that day must have come from someone else ... Got it. So, do we have anyone else who falls under the heading of someone else who could fill-in the gaps? Dave? I thought I did, but I don't. However, I do have a script that removes duplicate messages from an mbox, which you might find useful for those 801 duplicates. I should have said that the 2 directories are identical. Probably they were presented this way since they span 1999-2000. For all I know one could be a symlink to the other. -Eric Rz.
Re: [linux-audio-dev] Hunt for old list archives.
On Mon, Feb 19, 2007 at 05:25:05PM +0100, Marc-Olivier Barre wrote: Hi all, As discussed previously on this list, we are getting ready for a migration of the three LA* lists to linuxaudio.org. Many things are done to make our list better. One of them concerns archives. As you may have noted, LA* archives found on music.columbia.edu date back to 2002. Ico told me that there used to be an LA list hosted somewhere else way before that (1998). Having to do this migration, we will also migrate our archives. If possible it would be cool to be able to merge also the older archives in the whole. The question is, do some of you have any idea where I could find these archives, if they still exit... http://lalists.stanford.edu/ -Eric Rz.
Re: [Debconf-video] videos for debconf7?
On Tue, Feb 13, 2007 at 10:21:16AM -0600, Gunnar Wolf wrote: Henning Sprang dijo [Mon, Feb 12, 2007 at 02:34:09PM +0100]: Plus an online meeting after fosdem, I won't have time til then. Monday, 12th of March, 19 UTC? Hmm, I suddenly realize it's a stupid idea for me to propse an IRC meeting when I am just heading for a longer vacation :) I'll be available from April on - but I guess you can live well without me for the first meeting. I'm putting myself in a category similar to yours :) I want to participate in the video team this year, as I'm not core-doing any other organization tasks and I'm interested in the process. Of course, I'll act as a junior member of the team, and as such, I doubt I will join the meeting (blame my RL work, which seems to be actively trying to kill me by saturation). I'll also be there to help the video team (as a junior member). I'm most interested in helping with live streaming, but understand that the archival filming is the priority for most of you and will help with whatever needs doing. -Eric Rz. ___ Debconf-video mailing list Debconf-video@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-video
Re: [linux-audio-dev] sampler instrument definition standard needed
On Wed, Nov 22, 2006 at 08:12:19PM +0100, Leonard paniq Ritter wrote: On Wed, 2006-11-22 at 14:17 +0100, Christian Schoenebeck wrote: so i suppose the best way would be to reimplement sf2 as some kind of xsfz format, write a forth-back conversion library/utility and release the whole work under a bsd licence to make it easy for free and commercial developers to catch up... Sound Font is a dead end. One of the few things that was agreed by the majority on that list, was to use an XML based format for the articulation informations, probably encapsulated into a common compression format. Which makes sense, considering where we all come from. You know command line fetishists, light-weight text editor freaks. which is exactly what i was suggesting. i'm not calling to use sf2 as a standard, but using merely the order, metaphors and lingo of the format description so people feel at home, and mental mapping becomes easier. the new format will be extensible, so it's not bad to start off with a known feature set. it will take a few weeks until i have time for this, so be prepared :) A very late response ... but are you aware of libInstPatch: http://swami.sourceforge.net/devel.php -Eric Rz.
debconf7
I'm planning to go to debconf and wondered if anyone from debian-multimedia will be there. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381026: libphat0: New upstream version available
Package: libphat0 Version: 0.3.1-1.1 Severity: wishlist Phat has a new version available: http://prdownload.berlios.de/phat/phat-0.4.0.tar.gz Also there is a new upstream maintainer and location for the project: http://phat.berlios.de/ Thanks in advance for updating the debian package, Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[linux-audio-dev] [ANN] New specimen list and home
Hello all, I've set up a mailing list for specimen: http://zhevny.com/mailman/listinfo/specimen Additionally the web site now lives at http://zhevny.com/specimen. This is a minimal re-working of Pete's old site. More improvements to follow. Let me know if anything is badly broken. (I know the guide is broken, but I need to re-do it with new screenshots anyway.) I just changed the dns record for zhevny.com to point to a new host earlier today. The TTL was set to 1 day, so some of you may get pointed to the old box. Let me know if you have any issues, or just try again a little later. Thanks, Eric Rz.
Bug#369843: New libtheora release
Package: libtheora0 Version: 0.0.0.alpha5-1.1 xiph.org has released a new alpha release of libtheora. This includes optimizations from the theora-mmx branch. The release is available here: http://downloads.xiph.org/releases/theora/libtheora-1.0alpha6.tar.bz2 Release announcment on the main theora page: http://www.theora.org/ Thanks, -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Beowulf] Re: Reminder -- stream links for DCLUG meeting tonight
On Wed, May 17, 2006 at 05:03:37PM -0400, Eric Dantan Rzewnicki wrote: There will be live streams available for tonight's DCLUG meeting. The meeting is scheduled to start around 19:00. Check the DCLUG site for meeting topic and speaker info: http://dclug.tux.org URLs for the live video stream of the talk: Video (video and audio): http://streamer0.rfa.org:8000/dclug.theora.ogg http://streamer2.rfa.org:8000/dclug.theora.ogg Audio only (camera audio with the video stripped out): http://streamer0.rfa.org:8000/dclug.audio.ogg http://streamer2.rfa.org:8000/dclug.audio.ogg I'll be in #dclug on irc.freenode.net for live chat feedback. I'll try to have the stream up around 18:00 if you want to tune in early to sort out any client issues. The files of tonight's talk are available for download now. http://techweb.rfa.org/images/dclug/ Thanks to a suggestion from Serge, I also uploaded a vorbis only version for audio players. We'll see if we can arrange a podcast-ish solution for the future. -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED] ___ Beowulf mailing list, Beowulf@beowulf.org To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
[Beowulf] Re: Linux Cluster Forum/BWBUG meeting this afternoon
I messed up the URLs in my first mail. They are corrected below. The meeting should be starting in a few minutes. On Tue, May 09, 2006 at 10:50:39AM -0400, Eric Dantan Rzewnicki wrote: It will be streamed live again. The meeting is scheduled to start around 14:30 this afternoon. See the BWBUG site for meeting topic and speaker bio: http://www.bwbug.org/ Live video and audio streams of the talk will be available again. Video: http://streamer0.rfa.org:8000/bwbug.theora.ogg http://streamer2.rfa.org:8000/bwbug.theora.ogg Audio: http://streamer0.rfa.org:8000/bwbug.audio.ogg http://streamer0.rfa.org:8000/bwbug.audio.ogg -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED] ___ Beowulf mailing list, Beowulf@beowulf.org To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
Re: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen
On Fri, Apr 21, 2006 at 11:53:12AM +0200, Lars Luthman wrote: On Thu, 2006-04-20 at 13:20 -0400, Eric Dantan Rzewnicki wrote: On Thu, Apr 20, 2006 at 12:30:34PM -0400, Paul Winkler wrote: On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my disk) to: http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz I'm happy to host for the foreseeable future. If anyone's got a more recent copy let me know and I'll get that up as well. Great! I found a copy of 0.5.1 on my drive. Email me privately if you want it. umm ... the download just worked for me ... That said, I agreed a while back to maintain the project after Pete announced his own death and the accompanying death of specimen. While Pete resurfaced as a zombie and promptly went over to the dark side, I have not yet found time to resurrect specimen (mainly due to my job and preparations for LAC06). Great to hear that you are going to maintain it. When you start looking into it, could you also have a look at the LASH and JACK MIDI patches for it? It would be very nice to have those in the official releases. The JACK MIDI patch is here (it adds a JACK MIDI input port that can be used at the same time as the ALSA-seq port): http://www.student.nada.kth.se/~d00-llu/code_patches/specimen-jackmidi-051205.diff Dave Robillard's LASH patch is here: http://www.scs.carleton.ca/~drobilla/files/specimen-lash.patch I think both applied to 0.5.1 and the last CVS version I tested. Those are 2 things I'm interested in myself. So, yes I think there's a good chance of that functionality being added. I've grabbed copies of the patches. I'll look into them after LAC. -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen
On Thu, Apr 20, 2006 at 12:30:34PM -0400, Paul Winkler wrote: On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my disk) to: http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz I'm happy to host for the foreseeable future. If anyone's got a more recent copy let me know and I'll get that up as well. Great! I found a copy of 0.5.1 on my drive. Email me privately if you want it. umm ... the download just worked for me ... That said, I agreed a while back to maintain the project after Pete announced his own death and the accompanying death of specimen. While Pete resurfaced as a zombie and promptly went over to the dark side, I have not yet found time to resurrect specimen (mainly due to my job and preparations for LAC06). I fully intend to have a new home for specimen shortly after the conference. In the meantime, there is a copy of 0.5.1 available here: http://zhevny.com/specimen/files/ tarball, rpm and src rpm are there. I will maintain this location as the home of specimen files, so feel free to point the ebuilds there. My sincere apologies for not taking steps sooner. -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-user] Re: [linux-audio-dev] Re: [ANN] No More Specimen
On Thu, Apr 20, 2006 at 01:25:52PM -0400, Paul Winkler wrote: On Thu, Apr 20, 2006 at 01:20:07PM -0400, Eric Dantan Rzewnicki wrote: On Thu, Apr 20, 2006 at 12:30:34PM -0400, Paul Winkler wrote: On Thu, Apr 20, 2006 at 05:19:30PM +0100, Jonny Stutters wrote: I've uploaded a copy of specimen-0.4.5.tar.gz (the most recent on my disk) to: http://jeremah.co.uk/downloads/linux/specimen/specimen-0.4.5.tar.gz I'm happy to host for the foreseeable future. If anyone's got a more recent copy let me know and I'll get that up as well. Great! I found a copy of 0.5.1 on my drive. Email me privately if you want it. umm ... the download just worked for me ... ummm ... where? afaict it has been wiped off the face of gazuga.net. http://gazuga.net/specimen/files/ works for me ... can't imagine what would make it not work for you. But, anyway ... specimen has begun moving (if only slowly) to its new home. Maybe this is some sort of bizarre zombie communication system that indirectly says Give that Eric person a kick so I can get this stuff from my past life off my server. -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] Re: GPL Audio Hardware
On Wed, Apr 05, 2006 at 07:52:26PM -0500, Richard Smith wrote: Frankly I think 60+ channels is completely unrealistic (otherwise one would probably exist), but what do I know. If it's possible, hell yes put them in there. The hammerfall will do 52 so I don't see 60+ as that much of a stretch.. http://www.rme-audio.com/english/hammer/d9652.htm And there's the madi interface, too, with 128 channels: http://www.rme-audio.com/english/madi/hdspmadi.htm -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] regarding the 2nd Book Of Linux Music Sound
On Wed, Mar 29, 2006 at 02:20:57PM +0200, [EMAIL PROTECTED] wrote: Hi Dave, You don't have to do everything, you know. I would say that if I was to vote, I would vote for a community based project. This have to be closed ended, what I mean is since the projects themselves have much to gain by being included in such a book, if they are interested in the exposure why wouldn't they be interested in contributing. Beyond that if the publisher is agreeable to having two versions: one for sale and one free, then it could evolve into sorta a linuxaudio-docs project. IIRC, there was such an agreement with regard to Dave's book becoming the docs for the A/Demudi project at one point ... I would think this is an important project, but not to kill yourself over. Second that. I think everyone here wants Dave around for as long as possible in a coherent and healthy state. :) Aaron If I didn't just start a course and full-time techwriting, I would have said I would write it.. I would like to help, too, but then I seem to say that about way too many things. So, as usual I can't promise anything just yet. If I could just ditch my job and be a full time linux audio bum I would definitely help ... but, well, reality and all that ... -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: debian-multimedia-BOF at debconf6/MX?
Herman Robak wrote: On Fri, 24 Mar 2006 00:22:20 +0100, Junichi Uekawa [EMAIL PROTECTED] wrote: How many people will be attending debconf in Mexico in May 2006 ? I'd like to have maybe a session of sitting down and talking with a few people. +1 I would love to exchange wishes and assumptions, and have assumptions shot out of the water. The devil is in the corner cases. I am on the Debconf6 video team. Ah! will there be live streams of debconf6? How many folks are on the video team? -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [linux-audio-user] Re: [linux-audio-dev] More about consolidation of the Linux audio online resources
On Fri, Feb 24, 2006 at 04:15:52PM +0100, Esben Stien wrote: Eric Dantan Rzewnicki [EMAIL PROTECTED] writes: resources and bandwidth for Linux Audio stuff Why not grab this excellent opportunity to call it gnu audio. Should we have a different one for gnu/hurd audio when we start running that?;). then we could have GLADs and GHADs. eghads -- Eric Dantan Rzewnicki | Linux Audio Developer and Sysadmin Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] More about consolidation of the Linux audio online resources (was: linuxdj...)
On Fri, Feb 24, 2006 at 09:43:01AM +, Daniel James wrote: Hi Ico, hi Eric, That being said, in my department (Virginia Tech) I've got an ok to offer hosting for LA purposes which would mean direct physical access to the mainframe, virtually unlimited data storage (I am not sure how much we have right now but we should have probably close to 1TB and there is plenty of empty slots left on the mainframe for more disks to be added), and most importantly unlimited bandwidth That would be a great improvement, and would allow us to host or stream a lot of music files or offer software downloads. I can easily set up linuxaudio.org DNS to point to that. I notice Joern's mail concerning moving linuxdj content to linuxaudiodev.org and that somehow involving Paul ... I've been a little out of the loop lately. Can someone sketch in the current state of the various sites Ico is proposing to consolidate? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] More about consolidation of the Linux audio online resources (was: linuxdj...)
What type of hosting service does linuxaudio.org have now in terms of space, bandwidth, accesibility of physical site admins and access for remote site maintainers? On Sat, Feb 18, 2006 at 09:51:31PM -0500, ico wrote: Hi all, A couple days ago I sent an e-mail on this topic due to some initial positive feedback, yet not much has happened since... (it may very well be that a lot of people are very busy with LAC preparations (-: ). At any rate, please allow me to reiterate what I've mentioned before in hope that this time it may elicit some fruitful discussion on this IMHO very important topic. Best, Ico BEGIN-OLD-MESSAGE It appears to me that there were at least a few members of the LAD/LAU list who have expressed interest in having LAD site somehow integrated in the Linuxaudio.org. I believe that this would be a very encouraging step towards consolidating online LA resources into one site which would IMHO ultimately make LA users' lives a lot easier as well as make the overall LA scene look more professional to the outsiders/potential adopters. I see this kind of an idea as a first step towards a much more demanding goal--integration of other online resources, i.e. Dave's LA software page. I could see this integration happening via a single Wiki page that would contain detailed info/screenshots/documentation/mailing-list and other pertinent info for every LA software available out there. Naturally, linking these lists is also a possibility, yet the very thought of having one place with unified appearance that would provide all the necessary info, including documentation, application-specific mailing lists etc. seems IMHO truly inspiring. Such a project obviously bears a huge overhead. I can also see devs objecting to the redundancy of information that may be already available on their software's dedicated website. The solution to both problems would be asking devs and/or their project maintainers/helpers to assist with the generation of their software's Wiki page which should adhere to certain predetermined standards and then also providing a link to their original project's page. Yes, there would be some redundancy, but a vast number of projects could greatly benefit from such a consolidation, including one of the most important, yet often neglected aspects--proper documentation. For this reason, I would like to use this opportunity to possibly elicit a discussion on this matter and hopefully get the ball rolling :-). END-OLD-MESSAGE -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] More about consolidation of the Linux audio online resources (was: linuxdj...)
On Thu, Feb 23, 2006 at 04:12:09PM -0500, ico wrote: = Original Message From Eric Dantan Rzewnicki [EMAIL PROTECTED] = What type of hosting service does linuxaudio.org have now in terms of space, bandwidth, accesibility of physical site admins and access for remote site maintainers? Currently, the server hosting Linuxaudio.org has been arranged by Daniel James, so my guess is that it is hosted somewhere in UK, other info is unknown to me (ironically the site is currently inaccessible for whatever reason). Daniel? That being said, in my department (Virginia Tech) I've got an ok to offer hosting for LA purposes which would mean direct physical access to the mainframe, virtually unlimited data storage (I am not sure how much we have right now but we should have probably close to 1TB and there is plenty of empty slots left on the mainframe for more disks to be added), and most importantly unlimited bandwidth (although the actual outgoing line is limited to 100MBit from the node where the mainframe is, but the actual monthly bandwidth is unlimited). Finally, all data is backed-up weekly with one backup always being off-site in the case server melts down, dissapears, decides to grow legs and walk away, or whatever. Hope this helps! Best wishes, I also have a standing ok to offer RFA resources and bandwidth for Linux Audio stuff as well. Though at first impression I'm thinking an academic sponsor might be better for all concerned. If needed space and bandwidth are available here. I don't always have time to follow the lists, so mail me directly if I can be of service in this regard. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: portaudio in Debian, license updates?
Junichi Uekawa wrote: Hi, On Thursday 16 February 2006 22:49, Junichi Uekawa was like: Audio on the other hand seems to have mostly settled for ALSA and jack. (I'm not sure if portaudio is gone?) Things like portaudio and MIDIshare never really arrived. (OK, I'm exaggerating slightly - Doesn't Audacity use portaudio?) Audacity does use portaudio. Portaudio isn't dead and gone, but development is barely progressing. With portaudio-v19 audacity can use jack. The current portaudio snapshot seems to work ok, though audacity still creates and destroys jack ports with every record/play action. I don't know if there is any plan for an eventual release date of v19. However, portaudio looks non-free to me. http://www.portaudio.com/license.html: * Any person wishing to distribute modifications to the Software is requested to send the modifications to the original developer so that they can be incorporated into the canonical version. c.f. http://lists.debian.org/debian-legal/2004/11/msg00091.html However, it's included in Debian main, as part of source to audacity, and libportaudio. strange. I'm sending mail to request updated information on this topic; I don't know how this resolved. Hmm, I wasn't aware of that. Who are you mailing? I've had a few contacts with the main authors since RFA hosts the portaudio mailing list. If I can be of assistance let me know. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: starting audio applications via a common wrapper?
Junichi Uekawa wrote: Hi, What if we designed a wrapper to start audio applications accordingly? Here is a question: Do we want to start jack if it's not already started (always obey the symlinks that the sysadmin has set), or do we want to autodetect the current status ? It might be nice to have a helper command that just detects what sound daemon is running and help applications to use. Currently individual applications are doing their own checks in their own ways, which may sometimes have problems. RFA needs to have many users who can login to a given machine to run rivendell and audacity. Since the apps need to run as the same user as jack we've chosen to start jackd from a script chunk added to /etc/X11/XSession.d/. This way when the user logins via kdm (would work for gdm, xdm, etc, too) jackd is started as that user. We have some debconf choices set up in our packages to chose whether to start jackd on boot via an init script or on login as described above. Not exactly the wrapper idea being discussed here, but I thought it might add something to the discussion. ftp://ftp.techweb.rfa.org/debrfa/dists/sarge/main/ -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [linux-audio-dev] file format
On Tue, Oct 11, 2005 at 02:20:30PM +0200, Lars Luthman wrote: On Tue, 2005-10-11 at 01:02 +0200, fons adriaensen wrote: Hi all, For one of my current projects (to be presented at LAC2006) I'm looking for a suitable file format. Each file should contain: - A number of short (+/- 10 seconds) chunks of PCM audio. The number of channels will be different in each chunk. The only sample format required is single precision floating point. For multi-channel chunks, non-interleaved is preferred. All chunks will normally use the same sample frequency. - Metadata, both numerical and textual. The format should allow to have several chunks of these, and to add new ones later without breaking compatibility (i.e. readers will ignore parts they do not understand). There is no need for the audio to be usable with normal players - it's not meant to be listened to directly. Is there any standard file/container format that would provide for this sort of thing ? I've been looking at ogg, but it's a bit over the top - I don't need any streaming features. Both WAVE and AIFF are (R)IFF based, so you can put any 'chunks' of arbitrary data in them and they will still be valid WAVE or AIFF files. Which is why I suggested broadcast wav and cart chunk as those are simply standardised 'chunks'. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] file format
On Tue, Oct 11, 2005 at 01:02:59AM +0200, fons adriaensen wrote: Hi all, For one of my current projects (to be presented at LAC2006) I'm looking for a suitable file format. Each file should contain: - A number of short (+/- 10 seconds) chunks of PCM audio. The number of channels will be different in each chunk. The only sample format required is single precision floating point. For multi-channel chunks, non-interleaved is preferred. All chunks will normally use the same sample frequency. - Metadata, both numerical and textual. The format should allow to have several chunks of these, and to add new ones later without breaking compatibility (i.e. readers will ignore parts they do not understand). There is no need for the audio to be usable with normal players - it's not meant to be listened to directly. Is there any standard file/container format that would provide for this sort of thing ? I've been looking at ogg, but it's a bit over the top - I don't need any streaming features. The alternative is of course to have separate WAV files and some text file for the metadata, and combine all of this into a directory that would then be handled as a unit. But I'd prefer to have all data in a single file. Maybe braodcast wav files with cart chunk chunks. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
[linux-audio-dev] Re: [Jackit-devel] (1) Jack -- busted? (2) jack.udp -- busted? (3) jack-osx -- binary-only?
On Fri, Sep 23, 2005 at 12:10:15PM -0700, Stephen Travis Pope wrote: (2) My actual interest is in looking into the jack-udp protocol, and I tried getting this all to work on a Mac a few days ago and actually got much further, but it looks like file recv.c has problems since it doesn't appear to include any definition if the jackudp_t data type that it tries to declare in the first line of code; i.e., I get, /Users/stp/Code/jack/jack.udp/recv.c:14: error: 'jackudp_t' undeclared (first use in this function) Does jack.udp work in general? Is there any documentation of the actual protocol used? Has anyone thought of using TCP instead of UDP? Alban Peignier uses Rivendell with jack for radio broadcasts. As I understand it he uses jack.udp to send the audio from the broadcast box to a separate box that does encoding for web streaming. So, there is at least one working use case. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
[linux-audio-dev] Re: [Jackit-devel] Re: (1) Jack -- busted? (2) jack.udp -- busted? (3) jack-osx -- binary-only?
On Fri, Sep 23, 2005 at 12:28:00PM -0700, Stephen Travis Pope wrote: Hello again, I just answered question (2) about jack.udp when I realized that recv.c is #included in jack.udp.c (and itself includes packet.c). (I teach a graduate course on digital audio development, and this just made it onto the list of don't ever program like this.) Perhaps some more background would be helpful. I started to look at this after someone on the CLAM list mentioned the remote socket streaming protocol we use in the CREATE Signal Library (CSL, see http://www.create.ucsb.edu/CSL). We are currently discussing moving from UDP to TCP, and I'm interested in actual user experience with jack.udp. I notice that the server and client both fail and exit at the first sign of trouble (like out-of-sequence packets). There was some network traffic a couple of years ago about this. Is anyone using this regularly? Is anyone interested in collaborating on a common sample streaming protocol (possibly based on a somewhat simplified version of SDIF or the SC3 protocol)? There is definitely interest. See this recent thread from the LAU list: http://lalists.stanford.edu/lau/2005/09/0376.html -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] libcui - design-question
On Mon, Sep 19, 2005 at 04:39:34PM +0200, Mario Lang wrote: Alfons Adriaensen [EMAIL PROTECTED] writes: On Mon, Sep 19, 2005 at 10:46:26AM +0200, Mario Lang wrote: Whenever someone on LAD/LAU comes up with a scriptability question, I sincerely hope this is the day the LAD coder community will realize that merging core with GUI code is no good. I'll keep hoping, especially now that yet another app will be deguified soon! It's been noted on this list before, but just to put the word in again ... Many seeing users, such as myself, also prefer text interfaces. In my case mainly for scritability reasons but also because I rarely find gui metaphors useful to my personal ways of thinking and working. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: building jack packages for sarge
On Wed, Aug 31, 2005 at 11:22:53PM +0200, Guenter Geiger wrote: On Tue, 30 Aug 2005, Eric Dantan Rzewnicki wrote: Is it possible to build a package of jack 0.100.0 that would satisfy dependancies of other pacakges in sarge that depend on jack 0.99.0 / libjack0.80.0? Hi, Seems that I am the last one on this list :) The short answer: No Longer explication: The change of the package name of jack has been introduced because the jack ABI seems to have changed, so you have to recompile all the packages against the new ABI if they should work. In practice this depends on the calls that have been changed in libjack, and the ones used by the different programs, so it might work. So, in practice, we could lie to the package system and say that our libjack package built from jack 0.100.0 is libjack0.80.0 and only actually use applications that we know are ok with the new ABI? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [linux-audio-dev] Radio Scanner Recorder
On Tue, Aug 30, 2005 at 11:31:50AM -0400, Guillaume Filion wrote: Guillaume Filion a écrit : I'm a in the process of making a police/EMS/fire radio recorder. ... However, I started thinking and found that it would be better to have a different file for each segment. For example, if there is - 45 seconds of speech, followed by - 3 minutes of silence, followed by - 2 minutes of speech I would get two files, one 45 seconds long and one 2 minutes long. Does such a program allready exists, and if not, what would be the best/easiest way of doing it? Hi and thanks for your responses, I started playing with batchrec last night with good results. The source code is clean and compiled on the first try (on debian). I tried it on an old 200 MHz PC with 32 MB ram. I made a small perl script that runs every 5 minutes from a cron job. The script runs at low priority (with nice) and does some post processing on the wav files and recompresses them to 16 KHz 24 Kbps Mono MP3 files. From time to time, I get a Input/Output Error from batchrec, I guess this is because of the low system ressources. It might be a good idea to do the post processing on another PC. I'm not really familiar with jack, I took a look at the documentation but I would have to invest more time to get something out of it. For now, batchrec does the job pretty well. One thing that I would like to do would be to use a low pass filter because my scanner seems to emit some low frequency sounds that are louder than some parts of the conversations. If I understand jack correctly, it would allow me to plug a low pass filter in front of the recording program easily. You mean a high pass filter, right? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [a-devel] libc6 (bug 266507 finally is fixed!)
On Wed, Aug 17, 2005 at 08:24:06PM +0200, Andreas Kuckartz wrote: Quite a few of NPTL bugs have been fixed in libc6 version 2.3.5-3. Especially this one: NPTL (0.60) quirks with pthread_create (ignores attributes) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266507 Subscribers of this list (and other Linux Audio related lists) will remember that there have been heated debates regarding this bug and the delay of the application of a known patch. Thanks to the Debian glibc maintainers this problem finally has been resolved. Thanks a lot! I have had no crashes, no freezes or other problems so far with the new version. My suggestion therefore is to provide that version with DeMuDi. It is currently in Debian unstable. Do you happen to know if a backport for sarge of the fixed nptl is available? If not, what would it take to get one to backports.org? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[linux-audio-dev] Re: [linux-audio-user] www.linuxdj.com - down!
On Wed, Aug 17, 2005 at 12:53:46AM +0300, Kai Vehmanen wrote: On Fri, 12 Aug 2005, R Parker wrote: s. subject. down for me for quite a while already. And still seems to be. :( I guess Benno is still the admin contact for the site -- anyone got a more recent email address for him? Please somebody fix the server. I'm experiencing extreme lad mailing list archive withdrawl syndrome (elmlaws) disease. Fortunately the web archives are hosted on a different server: http://lalists.standford.edu The host appears to be up ... www.linuxdj.com.86400 IN A 66.98.132.90 $ ping 66.98.132.90 PING 66.98.132.90 (66.98.132.90): 56 data bytes 64 bytes from 66.98.132.90: icmp_seq=0 ttl=54 time=38.3 ms 64 bytes from 66.98.132.90: icmp_seq=1 ttl=54 time=38.2 ms The ftpd is up. I can telnet to port 80 ... but the service doesn't seem to be working properly. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-user] Re: [linux-audio-dev] [ANN] E-Radium V0.61b
On Thu, Jul 14, 2005 at 11:38:37AM +0300, Sampo Savolainen wrote: Quoting Eric Dantan Rzewnicki [EMAIL PROTECTED]: I'm confused ... most of us build our own kernels or use kernels built by Fernando or Free. Why can't kernels just be built with the config option set to 1000? Free? It's my turn to be confused. I've never heard of a such source for prebuilt kernels. Care to abbreviate? I'm sorry. I meant Free Ekanayaka, the current main Demudi developer. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-user] Re: [linux-audio-dev] [ANN] E-Radium V0.61b
On Wed, Jul 13, 2005 at 03:30:11PM -0700, Fernando Lopez-Lezcano wrote: On Wed, 2005-07-13 at 15:17, Eric Dantan Rzewnicki wrote: On Wed, Jul 13, 2005 at 02:20:20PM -0400, Lee Revell wrote: On Wed, 2005-07-13 at 13:52 -0400, Lee Revell wrote: On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan Rzewnicki wrote: What is driving the kernel-devs to regress on this issue? Saving battery on laptops. The only performance numbers anyone posted indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by ~5%, and this was after the fact. Not exactly compelling... But since Linus and Andrew apparently all use laptops, us desktop people are screwed... Any chance they would make it a config option? It is a config option, the available settings are 100, 250, and 1000. The problem is that the default has changed to 250. Update: Linus has said that this is a done deal. So now we need to figure out how to work around it. I guess we'll have to go back to using the RTC like on 2.4. I'm confused ... most of us build our own kernels or use kernels built by Fernando or Free. Why can't kernels just be built with the config option set to 1000? They can, what is changing is the default. Which means that out of the box normal distros will not be as suitable to reasonable midi timing as a tuned kernel. That was not the case in 2.6.x till now. I don't know about Free but I'd rather not be building kernels forever, it'd be nice that in a not too distant future regular unadulterated linux kernels would be good for audio/midi work... Yes. I'm sorry. I was thinking further about my comment all night. I realized that you and Free are working very hard at providing those kernels and anything that can make your lives easier will be a good thing. Looking forward 6 months to a year from now, I realize it will make my life much easier as I begin to deploy and maintain at least 30 and possibly as many as 100+ linux based broadcast workstations. Again, sorry for saying that. Lost my head there. Lee, your efforts are very much appreciated, too. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] [ANN] E-Radium V0.61b
On Tue, Jul 12, 2005 at 07:34:07PM -0400, Lee Revell wrote: On Wed, 2005-07-13 at 01:03 +0200, Florian Schmidt wrote: Some semieducated blabbering ahead (might be all wrong): I think i once read that interrupt handling short circuits the linux scheduler (in the sense that not only at every timer interrupt but also at the end of finishing any interrupt handler the kernel looks which processes are ready to run etc. and maybe there's a high prio process waiting just for that interrupt (by i.e. polling or reading on a device file). So for all those realtime processes that depend on events that are triggering interrupts (like soundcards' irqs) the timer interrupt really doesn't matter. I'm not sure at all though this applies to midi handling (and especially to alsa_seq when routing from one app to another) or is even correct in any sense at all :) Anyone can shed light? Correct, it's not an issue for apps driven by hardware interrupts like JACK, because the sound card consumes data at a constant rate. But for MIDI or video where you have to periodically push data to the device it matters. What is driving the kernel-devs to regress on this issue? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] [ANN] E-Radium V0.61b
On Wed, Jul 13, 2005 at 06:31:21PM +0200, Florian Schmidt wrote: On Wed, 13 Jul 2005 10:49:11 -0400 Eric Dantan Rzewnicki [EMAIL PROTECTED] wrote: Correct, it's not an issue for apps driven by hardware interrupts like JACK, because the sound card consumes data at a constant rate. But for MIDI or video where you have to periodically push data to the device it matters. What is driving the kernel-devs to regress on this issue? Well, i suppose it's a tradeoff between throughput and responsiveness. Larger timeslices increase system throughput (less time is spent in the scheduler) while smaller timeslices increase responsiveness. I expected something like this. But, I guess my question was more, who is complaining about HZ=1024? To which I guess the answer would be everyone who is more concerned about throughput than latency. Though, somehow I think that everyone needs a good balance between the two. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] [ANN] E-Radium V0.61b
On Wed, Jul 13, 2005 at 01:01:03PM -0400, Lee Revell wrote: On Wed, 2005-07-13 at 10:49 -0400, Eric Dantan Rzewnicki wrote: On Tue, Jul 12, 2005 at 07:34:07PM -0400, Lee Revell wrote: On Wed, 2005-07-13 at 01:03 +0200, Florian Schmidt wrote: Some semieducated blabbering ahead (might be all wrong): I think i once read that interrupt handling short circuits the linux scheduler (in the sense that not only at every timer interrupt but also at the end of finishing any interrupt handler the kernel looks which processes are ready to run etc. and maybe there's a high prio process waiting just for that interrupt (by i.e. polling or reading on a device file). So for all those realtime processes that depend on events that are triggering interrupts (like soundcards' irqs) the timer interrupt really doesn't matter. I'm not sure at all though this applies to midi handling (and especially to alsa_seq when routing from one app to another) or is even correct in any sense at all :) Anyone can shed light? Correct, it's not an issue for apps driven by hardware interrupts like JACK, because the sound card consumes data at a constant rate. But for MIDI or video where you have to periodically push data to the device it matters. What is driving the kernel-devs to regress on this issue? Saving battery on laptops. The only performance numbers anyone posted indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by ~5%, and this was after the fact. Not exactly compelling... But since Linus and Andrew apparently all use laptops, us desktop people are screwed... Any chance they would make it a config option? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-user] Re: [linux-audio-dev] [ANN] E-Radium V0.61b
On Wed, Jul 13, 2005 at 02:20:20PM -0400, Lee Revell wrote: On Wed, 2005-07-13 at 13:52 -0400, Lee Revell wrote: On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan Rzewnicki wrote: What is driving the kernel-devs to regress on this issue? Saving battery on laptops. The only performance numbers anyone posted indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by ~5%, and this was after the fact. Not exactly compelling... But since Linus and Andrew apparently all use laptops, us desktop people are screwed... Any chance they would make it a config option? It is a config option, the available settings are 100, 250, and 1000. The problem is that the default has changed to 250. Update: Linus has said that this is a done deal. So now we need to figure out how to work around it. I guess we'll have to go back to using the RTC like on 2.4. I'm confused ... most of us build our own kernels or use kernels built by Fernando or Free. Why can't kernels just be built with the config option set to 1000? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] Real time delay tutorials?
On Wed, Jul 13, 2005 at 03:22:42PM -0400, Paul Davis wrote: On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote: In realtime critical applications people prefer RTLinux or the RTAI extension to the kernel for periods and scheduling latencies in the low microseconds range (30 microseconds worst case scheduling latency on recent x86 hardware). I've often wondered about that. Why are those sorts of kernels inappropriate for audio? ( Just out of curiousity. ) what device drivers do you think they can run? ALSA (or some other driver infrastructure and drivers) would have to be ported to those environments. Or a new infrastructure and drivers for sound cards would have to be written from scratch. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] Why alsamixer starts with all the volumes settings in 0?
On Fri, Jul 01, 2005 at 12:01:28PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Hi everyone! I was just wondering why alsamixer starts with all volume settings in cero. I guess there should be an aswer to this, so I decided to ask you. What I didn't know was if to ask here or to lau's list, so I decided to go directly to the designers :-) It's by design so that people don't get their ears or speakers blown by default volumes being too high, asfaik. Also, it is possible to, at least, lstart with the main volume and pcm/wav just a little bit raised? I think this would help when configuring alsa, specially for newbies. The alsasound init script uses alsactl to store mixer settings when run with the stop case. On startup it restores those settings. Once you've installed alsasound in /etc/init.d/ and made the appropriate symlinks in your runlevel directories this happens automatically. Of course, it would probably help if this script got installed automatically. It comes with the alsa-drivers tarball. I'm not sure how demudi and ccrma deal with it. Ideally users shouldn't have to think about it. Thanks in advanced! Cheers, Damian.- Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read. -- Groucho Marx -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] Why alsamixer starts with all the volumes settings in 0?
On Fri, Jul 01, 2005 at 06:02:29PM +0200, Frank Barknecht wrote: Hallo, Lisandro Damián Nicanor Pérez Meyer hat gesagt: // Lisandro Damián Nicanor Pérez Meyer wrote: Hi everyone! I was just wondering why alsamixer starts with all volume settings in cero. To avoid broken loudspeakers. Also, it is possible to, at least, lstart with the main volume and pcm/wav just a little bit raised? I think this would help when configuring alsa, specially for newbies. One of your start scripts, notmally /etc/init.d/alsa or /etc/init.d/alsasound, should contain a call to alsactl, which stores mixer settings on shutdown and recalls them on reboot. What distribution are you on? oops. frank beat me to it. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
removing file tapes
I can't seem to get amanda to really forget about some file tapes. I've removed them with: amrmtape rfaset1 rfaset1-slot1-9 They are no longer listed in tapelist. but when I run amcheck I get messages like these for each of the removed tapes: amcheck-server: slot 4: rewinding tape: Input/output error ERROR: /file_tapes0/rfaset1/data/: No such file or directory ERROR: /file_tapes0/rfaset1/data/: No such file or directory Additionally amcheck reports: ERROR: new tape not found in rack (expecting a new tape) If I manually recreate the /file_tapes0/rfaset1/data link to point to one of my as yet unused vtapes amcheck is happy for that day and that night's amdump runs fine. But, the next day amcheck reports the same errors. Somehow the 9 removed vtapes are still being considered part of my tapecycle and the last 9 tapes are not being used automatically. Any suggestions? I've been looking through the docs but don't see this situation described anywhere. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: removing file tapes
On Thu, Jun 30, 2005 at 03:15:07PM -0400, Eric Dantan Rzewnicki wrote: I can't seem to get amanda to really forget about some file tapes. I've removed them with: amrmtape rfaset1 rfaset1-slot1-9 They are no longer listed in tapelist. but when I run amcheck I get messages like these for each of the removed tapes: amcheck-server: slot 4: rewinding tape: Input/output error ERROR: /file_tapes0/rfaset1/data/: No such file or directory ERROR: /file_tapes0/rfaset1/data/: No such file or directory Additionally amcheck reports: ERROR: new tape not found in rack (expecting a new tape) If I manually recreate the /file_tapes0/rfaset1/data link to point to one of my as yet unused vtapes amcheck is happy for that day and that night's amdump runs fine. But, the next day amcheck reports the same errors. Somehow the 9 removed vtapes are still being considered part of my tapecycle and the last 9 tapes are not being used automatically. Any suggestions? I've been looking through the docs but don't see this situation described anywhere. 2.4.4p3-3 debian sarge package -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] Midi/OSC help - Continuous controllers
On Wed, Jun 29, 2005 at 01:44:18AM +0200, Olivier Guilyardi wrote: Hi Paul, 1 - a friend of mine showed me his brand new evolution uc33 midi controller. He's using that with a windows-based software called Live. I was really suprised to see that this software use exactly what I proposed in this thread. First you enter a capture-mode, you click on some GUI widget, then you rotate some knob, that's it : it's assigned. I promise I never saw a such thing when I had exactly the same idea. Doesn't ardour allow this type of binding midi CC's to mixer controls? 2 - Tonight, I went to a concert of a jazz drummer, a friend of mine. He was using a macintosh coupled with a midi h/w controller. He spent more time playing with this computer than with his drumset, but nevermind... My point is : he was using both the midi controller, and the screen/keyboard/mouse set, just as my other friend above. Now, here's what I consider to be a very practical consideration : there are many GUI enabled apps, which can't run headless. A usual way of using a midi h/w controller is as a add-on, not as a replacement for the screen. I'd personally like to use a such midi h/w as a standalone device, on stage, but nothing will forbid me to unplug the screen in this case... By midi-enabling some toolkit widgets, _many_existing_ apps would suddenly become compatible with these dedicated controller hardware devices. I do agree you that the best would be for these apps to add some midi input support, as a separated View. But on the other side, what about the capture-style way of assigning knobs to widgets ? Don't you see how this is efficient ? In 1 second, what you touch on the controller is connected with what you see on your screen (WYTIWYS ;-). Still, of course, in this case you may say that these are two separated layers that artificially appear to be one... But what about a shortcut to couple these two layers, if they are to get so tight ? I believe there could exist a library with which : 1 - you instantiate a core object (providing the alsa midi port as an arg) 2 - you attach to some widgets : sliders, spin buttons, etc.. (note that this is different from extending (bloating) widgets) 3 - you may call a function to enter the capture-mode 4 - 100 % of this capture-mode is encapsulated by the library : knobs-to-widgets assignations are handled transparently 5 - there is some way to retrieve these assignations to recall them later How does all this differ from midikinesis? http://lac.zkm.de//2005/proceedings.shtml -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
firewall/nat issues
Is this entry in the FAQ a complete description of the network interactions between amanda client and amanda server? http://amanda.sourceforge.net/fom-serve/cache/139.html I'm not relishing the thought of working this out in ipchains ... I'm pushing to (finally) move to iptables. But, I may have to make it work with ipchains for now, so I need to get a clear understanding of what type of which ports need to be openned up. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: firewall/nat issues
On Tue, Jun 28, 2005 at 04:30:17PM +0200, Stefan G. Weichinger wrote: Eric Dantan Rzewnicki wrote: Is this entry in the FAQ a complete description of the network interactions between amanda client and amanda server? http://amanda.sourceforge.net/fom-serve/cache/139.html I'm not relishing the thought of working this out in ipchains ... I'm pushing to (finally) move to iptables. But, I may have to make it work with ipchains for now, so I need to get a clear understanding of what type of which ports need to be openned up. For iptables: http://www.amanda.org/docs/faq.html#id2555136 and the main info: http://www.amanda.org/docs/portusage.html I'd also recommend to search the archives for terms like iptables/ipchains/firewall, there have been some threads lately ... Yes. Thank you. I've read all of that and now have re-read it. I think the best answer is to get our firewall updated to using iptables and the amanda connection tracking module. But, that is a separate project with separate management decisions to be made. I don't think I can get this to work in a non-ugly way with our current ipchains, linux kernel v2.2 based solution. The initial udp packet from the amanda server on internal lan to the amanda client on the external lan gets there, but is masqueraded to a high port by the firewall. So, the amandad on the client says: ERROR: client.dom.tld : [host router.dom.tld: port 64781 not secure] As far as I can figure out there isn't a way for me to prevent the source port from being masqueraded using ipchains. Please correct me if I am wrong. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: firewall/nat issues
On Tue, Jun 28, 2005 at 02:46:12PM -0500, Frank Smith wrote: --On Tuesday, June 28, 2005 15:09:42 -0400 Eric Dantan Rzewnicki [EMAIL PROTECTED] wrote: As far as I can figure out there isn't a way for me to prevent the source port from being masqueraded using ipchains. Please correct me if I am wrong. It's been so long since I used ipchains I couldn't say for sure. One possible interim workaround for you until you get your firewall issues resolved: Use rsync to keep a copy of the remote DLE's on an internal server (rsync can even use exclude files), and then use Amanda to back up the local copy. This method also works well for remote machines on low bandwidth links, since rsync is just doing incremental changes, so your level 0's don't have to drag all the data over a slow link each time it runs. The rsync solution is exactly what I just settled on moments ago. Thanks. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: Question of Use (-or- Am I trying to use an Uzi to kill gnats)
On Fri, Jun 24, 2005 at 03:47:55PM -0400, Roger Wilber wrote: I've been looking for software that will allow me to backup my large amount of data as simple tar archives on DLT tapes for permanent archival. This will happen only once and will be the final backup of the data EVER. I do not get to choose the type or format of tapes used nor do I get to choose the archive format (otherwise our pre-existing Networker backups would be just fine). Networker can not write to the tapes in a simple tar archive so that is out. The question comes down to simply this - does Amanda hold any promise of making this task easier or am I still left to manually breaking up my 6TB of data into nice 35 - 40GB bites and shoving them at the tapes? Amanda doesn't yet support spanning tapes, afaik. So, you would have to break it up. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
restore file from windows client
Is there a document on how to restore files backed up via smbclient from a windows host? I'm looking through the docs and list archives, but can't seem to find it. :-/ -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] Re: What Parts of Linux Audio Simply Work Great?
On Tue, Jun 14, 2005 at 07:09:38PM +0200, Richard Spindler wrote: Hi, I'm actually amazed that there is still no premium Linux-Workstation Integrator that ships well selected Linux-Boxes with a custom Linux-Distribution that's exactly fitted to the Hardware. That'd be hard to beat. http://www.penguincomputing.com/products/workstations/index.php -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] disaster day #3
On Wed, Jun 08, 2005 at 10:32:38PM +0200, Jens M Andreasen wrote: On Wed, 2005-06-08 at 15:22 -0400, Dave Phillips wrote: Greetings: While waiting for another box I decided to pull the RAM and test each stick (256 MB each). The problem occurred with either stick. I'm able to log in, work for a few minutes, then the box just freezes. I can hear the disk drive make a little activity noise first, then everything's just gone. Btw, it'll die in X or at the console, it's not an X problem Will it die if you go into BIOS set-up, and just leave it there for a few minutes? If so, it could be a cooling or overclocking problem. Like a dead or dusty CPU-fan or perhaps a jumper on its way to fall off. I missed most of this thread, so I'm sorry if this has already been said. But, have you run memtest? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: Samba 3.0.14 problems with Amanda 2.4.4p3?
On Thu, May 19, 2005 at 09:04:46PM +0200, [EMAIL PROTECTED] wrote: Hello, Filip, on 19.05.2005, 19:05 you wrote to amanda-users@amanda.org: FR At 05/18/05 19:35, Bryan K. Walton wrote: FR (...) FR Same here, with Amanda 2.4.5 / Samba 3.0.13, running slackware-current with FR 2.4.30 kernel. In client-src/sendbackup-gnutar.c there are regular expressions defined which help to hide several Samba-messages from the AMANDA-reports. This small one-line-patch removes the Samba-Domain-messages: --- standard/sendbackup-gnutar.c 2004-10-12 22:47:52.0 +0200 +++ patched/sendbackup-gnutar.c 2005-05-11 18:20:58.314182688 +0200 @@ -120,2 +120,3 @@ AM_ERROR_RE(ERRDOS - ERRbadpath (Directory invalid.)), + AM_NORMAL_RE(^Domain=), #endif Has there been any discussion in the past of breaking these regular expressions out into a simple text file that amanda checks at runtime? Something like logcheck's settup might be nice. That way each site can configure it's own set of expressions to ignore without having to recompile. Of course, I expect the answer to include show us the code. But, I'm somewhat new to the list so I don't know if this has been suggested before. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: Re[2]: Is everybodies amanda running perfect? Boggles the mind.
On Sun, May 29, 2005 at 02:07:59PM -0400, Gene Heskett wrote: On Sunday 29 May 2005 07:59, [EMAIL PROTECTED] wrote: Hello, Gene, on 29.05.2005, 04:14 you wrote to amanda-users@amanda.org: GH On Saturday 28 May 2005 21:35, Gene Heskett wrote: No mail from the list in about 20 hours, so lets see what happens to this message... GH Humm, round trip, 10 minutes max. I must be the only idiot near a GH computer on this holiday weekend. Second idiot here. Glad to now I'm not alone. I really should round up the missus and go someplace just to say we went someplace on memorial day, like maybe down to Green Bank, but this is the weekend one can get killed on the roads too easily... Besides, I hear a shovel calling my name out at Too true. It took more than twice as long as it should to get back to DC from Raleigh last night. From what I understand there were at least 3 serious accidents. the retaining wall I'm building. The weather is so-so and I'm trying to ignore it, sitting here about half PO'd cause Dish doesn't have an ABC feed the Indy 500 is today. I hope Danica does well. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: amanda on RedHat ES 3 backup on HDD
On Sun, May 29, 2005 at 02:50:53PM -0400, Gentian Hila wrote: It it my first time trying to use AMANDA for backup. I went ahead and read the chapter on amanda from the book Backup and recovery in Unix, but it seemed to me very complicated. I have a RedHat ES 3 system and I am using an external usb HDD to backup the whole system. I want to do a full backup once a week and incremental backups every other day of the week. This isn't the way amanda works. See the friday-tape-question: http://www.amanda.org/docs/topten.html#id2555117 -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
using several NFS mounts as file tape
I'm using the file driver for virtual tapes. The vtapes will live on several NFS mounts. It's easy enough to mount these on several mount points and link the tapes into a common directory. That's what I've been doing and it works fine. But, I was wondering if this is how others are doing it. The current plan looks like this: /file_tapes11.4TB NFS mount /file_tapes21.4TB NFS mount /file_tapes3~900GB NFS mount /file_tapes0/rfaset1/ contains links to slotNN directories in each of the NFS directories. Seems to work fine. But, I just wondered if all slots necessarily have to look like they live in the same directory. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: Debugging lufs vtape and amanda flushing-throtle for amanda
On Wed, May 25, 2005 at 03:23:34PM +0200, Vlad Popa wrote: Hi Jon , Jon LaBadie schrieb: On Tue, May 24, 2005 at 11:53:57PM +0200, Vlad Popa wrote: Hello Jon ! Jon LaBadie schrieb: On Mon, May 23, 2005 at 12:05:21PM +0200, Vlad Popa wrote: I'll ask Paul's question slightly differently. How can you WANT to run any slower (see below). DUMP SUMMARY: HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s -- - h50234 /etc02440 2440 --0:03 930.1 9:26 4.3 This was your biggest, and speediest successful taping. It only ran at 4300 bytes/sec Something is seriously wrong with your network connection to your vtape. I strongly urge you to fix your network connection rather than continue to try to get amanda (or any application) to work with a broken network. You are absolutely right Jon, but I cannot tweak more the lufs. I was thinking more of the hardware end of the setup. There have been frequent mentions of poor network performance when a switch and host are not configured correctly. Sometimes depending on the auto-config feature of the switch or host does not give the best connection. I have tested native ftp transfers to this host (beside lufs) which were at about 4.3 mb per sec (ftp hostname and then put file ..) for several files differring significantly in their size. The rate did not fall below 4 megs per sec. Just an interesting observation, amanda sees 4.3 kb/sec, you got 4.3 mb/sec for ftp transfers. No other way to access that remote disk than still beta lufs and ftp? Nope, no other way than ftp access. Using lufs or not using it is up to me. I will never see this server . We have rented a root server which is probably located in Berlin or elsewhere. The rent is including access to a ftp share on their server for backups) . We have only some kind of console and ssh access. If you have ssh access you should be able to use rsync, no? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: tar versions (was Re: implausibly old time stamp)
On Wed, May 25, 2005 at 05:57:43PM +0200, Alexander Jolk wrote: Jon LaBadie wrote: Perhaps no postings about the specific problem, but lots where the response was to use 1.13.25, 1.13.19, or maybe 1.14.1. Latter one is fairly new, so my jury is still out deliberating :) BTW I had run into a restoring problem with (Debian sarge's) tar-1.14, due to `sparse archive members'. As had been discussed on this list a few times already, installing tar-1.15.1 fixed the problem, I could restore from the existing archives without any problem. Did you compile from source or use the debian package from sid? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: Debugging lufs vtape and amanda flushing-throtle for amanda
On Wed, May 25, 2005 at 03:08:02PM -0400, Eric Dantan Rzewnicki wrote: On Wed, May 25, 2005 at 03:23:34PM +0200, Vlad Popa wrote: Hi Jon , Jon LaBadie schrieb: On Tue, May 24, 2005 at 11:53:57PM +0200, Vlad Popa wrote: Hello Jon ! Jon LaBadie schrieb: On Mon, May 23, 2005 at 12:05:21PM +0200, Vlad Popa wrote: I'll ask Paul's question slightly differently. How can you WANT to run any slower (see below). DUMP SUMMARY: HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s -- - h50234 /etc02440 2440 --0:03 930.1 9:26 4.3 This was your biggest, and speediest successful taping. It only ran at 4300 bytes/sec Something is seriously wrong with your network connection to your vtape. I strongly urge you to fix your network connection rather than continue to try to get amanda (or any application) to work with a broken network. You are absolutely right Jon, but I cannot tweak more the lufs. I was thinking more of the hardware end of the setup. There have been frequent mentions of poor network performance when a switch and host are not configured correctly. Sometimes depending on the auto-config feature of the switch or host does not give the best connection. I have tested native ftp transfers to this host (beside lufs) which were at about 4.3 mb per sec (ftp hostname and then put file ..) for several files differring significantly in their size. The rate did not fall below 4 megs per sec. Just an interesting observation, amanda sees 4.3 kb/sec, you got 4.3 mb/sec for ftp transfers. No other way to access that remote disk than still beta lufs and ftp? Nope, no other way than ftp access. Using lufs or not using it is up to me. I will never see this server . We have rented a root server which is probably located in Berlin or elsewhere. The rent is including access to a ftp share on their server for backups) . We have only some kind of console and ssh access. If you have ssh access you should be able to use rsync, no? Or perhaps try scp just to see if the slowness is specific to lufs/ftp. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: Wait for dumping question
On Tue, May 24, 2005 at 03:13:13PM +0800, Ryan Pagquil wrote: Jon LaBadie wrote: On Sat, May 21, 2005 at 02:23:21PM +0800, Ryan Pagquil wrote: Guys, Who will be the responsible for the dump when the amanda said that the host's status is wait for dumping? If I understand correctly, you started a dump and while it was running you ran amstatus. The report from amstatus showed some DLEs waiting for dumping. Probably totally normal. If you had 1000 DLE's you would not want them all dumping at the same time. Something would overload. So amanda has several restraints on what DLE dumps when. Max number total running at the same time, max per host, max per spindle, ... Plus there are priorities and other things that may affect when a particular DLE gets dumped. It is more important whether you see it has been dumped when amdump has completed. so it is normal amanda do this. btw, what does DLE stands for... another http://www.amanda.org/docs/topten.html#id2554702 -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: Debugging lufs vtape and amanda flushing-throtle for amanda
On Tue, May 24, 2005 at 11:53:57PM +0200, Vlad Popa wrote: Hello Jon ! Jon LaBadie schrieb: On Mon, May 23, 2005 at 12:05:21PM +0200, Vlad Popa wrote: Dear Paul, Paul Bijnens schrieb: Vlad Popa wrote: So how can I say Not so fast, Mrs. Amanda ! when taping ? Are you 100% sure that is the problem?? I'll ask Paul's question slightly differently. How can you WANT to run any slower (see below). DUMP SUMMARY: HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s -- - h50234 /etc02440 2440 --0:03 930.1 9:26 4.3 This was your biggest, and speediest successful taping. It only ran at 4300 bytes/sec 1/4 megabyte per minute 15 megabytes per HOUR If you will pay me, I'll hand write the data. It might be faster :)) Jon, I'd pay you the money , If I had one (since I 'd be sure the data written by you is hand-signed, certificated and prooved to be on my vtape..) Something is seriously wrong with your network connection to your vtape. I strongly urge you to fix your network connection rather than continue to try to get amanda (or any application) to work with a broken network. You are absolutely right Jon, but I cannot tweak more the lufs. I'm afraid, I have to discard this meant-to-be solution. I get to the conclusion, that lufs project is not (yet) mature enough to work in a amanda scenario when using the ftp feature in my case. (I cannot say something about the other parts..) I'd rather have a native ftp-client-based (some kind of a vftape extension..) amanda solution (I do apologise, I'm not a coder ..) than this lufs for my situation working now. The only performance improovement I could test was being logged in several times on the server (using more lufs channels) but the result was the same. I have tested native ftp transfers to this host (beside lufs) which were at about 4.3 mb per sec (ftp hostname and then put file ..) for several files differring significantly in their size. The rate did not fall below 4 megs per sec. I like amanda's features because it is really flexible and powerful. Do you see any solutions working for my situation without abandoning using amanda? What about vtape-ing locally and transfering the directory by Mr. Cron to the ftp server ? (for this I needed a automatic script-based ftpclient for upload as wget is for download ) I'm still focused on onsite backups using vtapes. But, eventually I'm thinking of using rsync to copy vtapes to some (yet to materialize) offsite storage facility. I'm not sure how to decide what to keep offsite as I will likely have much more onsite storage. Perhaps if I have, say, 40 days worth of vtape space (tapecycle = 40 tapes) on site I'll shoot for keeping the most recent dumpcycle's worth of vtapes off site. I usually use rsync with rsh=ssh. I'm not sure if rsync can use ftp. Is ftp the only protocol you can use to access your off site storage? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
sendsize for winNT client fails
I have been able to backup one of our WinNT servers, server1, with amanda without problems. But, when I add a second WinNT server, server2, sendsize never finishes. /tmp/amanda/sendsize.20050520190001.debug shows the server1 DLE estimates finishing normally, but server2 starts out like this: . sendsize[3036]: time 2132.419: child 3186 terminated normally sendsize[3036]: time 2132.419: waiting for any estimate child: 1 running sendsize[3189]: time 2132.419: calculating for amname '//rfaserver2/C$', dirname '//rfaserver2/C$', spindle -1 sendsize[3189]: time 2132.419: getting size via smbclient for //rfaserver2/C$ level 0 sendsize[3189]: time 2132.419: spawning /usr/bin/smbclient in pipeline sendsize[3189]: argument list: smbclient \\rfaserver2\C$ -d 0 -U backup -E -c archive 0;recurse;du sendsize[3189]: time 2132.520: Domain=[RFA] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0] sendsize[3189]: time 21861.647: Memory allocation error: failed to expand to 2142469492 bytes sendsize[3189]: time 21861.726: cli_list_new: Failed to expand dirlist sendsize[3189]: time 22898.950: Memory allocation error: failed to expand to 2142466728 bytes sendsize[3189]: time 22898.983: cli_list_new: Failed to expand dirlist sendsize[3189]: time 69960.002: Memory allocation error: failed to expand to 1605591708 bytes sendsize[3189]: time 69960.030: cli_list_new: Failed to expand dirlist sendsize[3189]: time 70771.322: Memory allocation error: failed to expand to 1605592120 bytes sendsize[3189]: time 70771.343: cli_list_new: Failed to expand dirlist sendsize[3189]: time 71557.874: Memory allocation error: failed to expand to 1605593984 bytes sendsize[3189]: time 71557.900: cli_list_new: Failed to expand dirlist sendsize[3189]: time 72317.135: Memory allocation error: failed to expand to 1605593568 bytes sendsize[3189]: time 72317.153: cli_list_new: Failed to expand dirlist sendsize[3189]: time 73109.909: Memory allocation error: failed to expand to 1605592124 bytes sendsize[3189]: time 73109.927: cli_list_new: Failed to expand dirlist sendsize[3189]: time 73891.863: Memory allocation error: failed to expand to 1605591708 bytes sendsize[3189]: time 73891.884: cli_list_new: Failed to expand dirlist sendsize[3189]: time 73892.366: Memory allocation error: failed to expand to 1073741824 bytes sendsize[3189]: time 73892.443: failure enlarging do_list_queue to 1073741824 bytes sendsize[3189]: time 73892.449: failure enlarging do_list_queue to 0 bytes sendsize[3189]: time 73892.449: failure enlarging do_list_queue to 0 bytes sendsize[3189]: time 73892.449: failure enlarging do_list_queue to 0 bytes and goes on like that until the / partition is full. This has happened twice with the sendsize.date-stamp.debug file growing to 14GB. For tonight's run I've commented out the C$ share in disklist and will try another share on the same server to see if it is specific to the share, or a more general problem with this server. The backup server is a debian sarge gnu/linux with amanda 2.4.4p3-2 and samba 3.0.14a-1. I believe I have amanda configured correctly as I am able to back up the other WinNT server without issues. My amanda server is also the smbclient host. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: holding disk with vtapes?
On Tue, May 17, 2005 at 09:38:32PM +0200, Stefan G. Weichinger wrote: Hi, John, on Dienstag, 17. Mai 2005 at 20:16 you wrote to amanda-users: JY Folks, JYIf you are using vtapes on a RAID for your backup JY media, is there any point to also using a holding disk? JY I can easily understand the use of a holding disk if JY you are using real tapes but am not sure what it buys JY you if you are using vtapes. Any comments? As already mentioned in the HOWTO the main benefit of using a holdingdisk is increasing parallelity. So it also makes good sense to use it with vtapes also. Is it normal for some dumps to go directly to tape, skipping the holding disk? I see that happening sometimes, but wonder if it means I have something misconfigured. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: holding disk with vtapes?
On Wed, May 18, 2005 at 02:38:59PM -0500, Frank Smith wrote: --On Wednesday, May 18, 2005 15:17:51 -0400 Eric Dantan Rzewnicki [EMAIL PROTECTED] wrote: Is it normal for some dumps to go directly to tape, skipping the holding disk? I see that happening sometimes, but wonder if it means I have something misconfigured. One thing that will cause that is if there's not enough room on the holdindisk. Hmm. I think I must have something messed up then. My holding disk is ~300GB and all my DLE's are under ~60GB compressed. Most DLE's are only a few gigs. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: holding disk with vtapes?
On Wed, May 18, 2005 at 09:47:29PM +0200, Paul Bijnens wrote:
Eric Dantan Rzewnicki wrote:
Is it normal for some dumps to go directly to tape, skipping the holding
disk?
I see that happening sometimes, but wonder if it means I have something
misconfigured.
Those DLE's with an estimated size larger than the configured value
for holdingdisk will bypass holdingdisk an dump directly to tape.
I noticed that the example amanda.conf file has specified use 290 m
for the holdingdisk section.
Many people seem to forget to adapt that arbitrary number there.
I have holding disk defined like this:
holdingdisk holding {
directory /holding
use 0
chunksize 0
}
#diskdir /holding # where the holding disk is
#disksize 295 MB# how much space can we use on it
the 2 commented out option were in the example config and I was using
those for awhile, but noticed that these, diskdir and disksize, are not
in man amanda, while the holdingdisk name {} is.
I didn't start a new thread on this because like the OP I'm using
filetapes and am on Debian Sarge: amanda 2.4.4p3-2, 3.0.14a-1. Clients
are a mix of Win NT, Win2k, Debian Sarge and Debian Woody (amanda
2.4.2p2-4).
I'm beginning to wonder if I need to roll my own amanda debian packages
...
gah ... nevermind ... I've been reading that disksize 295MB as 295GB
until now ... just noticed as I was about to hit send.
But, which of those 2 ways of specifying the holding disk is correct?
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
[EMAIL PROTECTED]
Re: holding disk with vtapes?
On Wed, May 18, 2005 at 05:02:53PM -0400, Jon LaBadie wrote:
On Wed, May 18, 2005 at 03:58:35PM -0400, Eric Dantan Rzewnicki wrote:
On Wed, May 18, 2005 at 09:47:29PM +0200, Paul Bijnens wrote:
Eric Dantan Rzewnicki wrote:
Is it normal for some dumps to go directly to tape, skipping the holding
disk?
I see that happening sometimes, but wonder if it means I have something
misconfigured.
Those DLE's with an estimated size larger than the configured value
for holdingdisk will bypass holdingdisk an dump directly to tape.
I noticed that the example amanda.conf file has specified use 290 m
for the holdingdisk section.
Many people seem to forget to adapt that arbitrary number there.
I have holding disk defined like this:
holdingdisk holding {
directory /holding
use 0
chunksize 0
}
#diskdir /holding # where the holding disk is
#disksize 295 MB# how much space can we use on it
the 2 commented out option were in the example config and I was using
those for awhile, but noticed that these, diskdir and disksize, are not
in man amanda, while the holdingdisk name {} is.
I didn't start a new thread on this because like the OP I'm using
filetapes and am on Debian Sarge: amanda 2.4.4p3-2, 3.0.14a-1. Clients
are a mix of Win NT, Win2k, Debian Sarge and Debian Woody (amanda
2.4.2p2-4).
I'm beginning to wonder if I need to roll my own amanda debian packages
...
gah ... nevermind ... I've been reading that disksize 295MB as 295GB
until now ... just noticed as I was about to hit send.
But, which of those 2 ways of specifying the holding disk is correct?
The one you are using. Here is one of my 3 HD definitions.
Are diskdir and disksize deprecated? if so I'll file a bug with the
debian maintainer to have the example config in the deb package changed.
reserve 20 # amount of holding disk to reserve for incrementals
autoflush yes
holdingdisk hd1 {
comment main holding disk
directory /w/dumps/amanda/DS1
use -2 Gb
#chunksize 512 Mb
}
Thanks.
What are the implications of using larger vs. smaller chunksizes for the
holding disk? man amanda says the default is 1GB. Are many 1GB files
better for performance or for some other consideration than one big
size_of_dumpGB file?
use -2 Gb means to use all but 2Gb of the holding disk. Do you do this
to avoid filesystem performance issues that may occur if it were allowed
to fill completely?
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
[EMAIL PROTECTED]
Re: Request for enhancement - Auto dle
On Fri, May 13, 2005 at 09:36:27PM +0200, Stefan G. Weichinger wrote: Hi, Chris, on Freitag, 13. Mai 2005 at 19:20 you wrote to amanda-users: CL It would be great if we could tell amanda that all subdirectories of a CL specific root were to be treated as individual disk list entries. i.e. CL balance all sub directories across backups. I don't want to sound lazy, but isn't this solved pretty easily by some kind of shell-script that you run regularly? This is the kind of laziness all good sysadmins should practice. ;) If this script finds some new directory inside that given dle-root-directory it appends a new DLE to your disklist. Find all the dirs under dle-root-dir, compare them to a list of already existing DLEs, if something is new, add DLE to disklist. I have to admit that this new auto-DLE-feature inside AMANDA would also look good to me ;-) This would mean we would need some kind of new parameter inside amanda.conf, maybe dleroot yes/no (default: no) ? PAW (according to Jon LaBadie this means Stefan G. Weichinger writes : Patches Always Welcome) ;-) -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: gpg with amanda
On Tue, May 10, 2005 at 03:07:07PM -0700, Mike Delaney wrote: On Tue, May 10, 2005 at 05:39:21PM -0400, Eric Dantan Rzewnicki wrote: I had a link for using gpg with amanda, but can't find it. Does anyone have the URL handy? http://www.google.com/search?q=gpg+amanda duh. sorry. :-/ -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
gpg with amanda
I had a link for using gpg with amanda, but can't find it. Does anyone have the URL handy? Thanks, -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] Linux Audio Conference 2005 Live Audio/Video streams
On Sat, Apr 23, 2005 at 11:48:54AM -0700, Brad Fuller wrote: Eric Dantan Rzewnicki wrote: (are you saving the streams?) Yes. They are available here: http://www.linuxdj.com/audio/lad/contrib/zkm_meeting_2005/ I want to thank everyone who has been responsible for these streams! I was planning to go but couldn't make it - so this is a wonderful alternative. Unfortunately, not being there means I'm not able to meet everyone at the conf and that would have been fun (hey, there's a product idea: virtual networking - in the personal sense, of course) Again, thanks! Great! glad to hear you enjoyed it. It's been a lot of fun. :) -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: [linux-audio-dev] Linux Audio Conference 2005 Live Audio/Video streams
On Thu, Apr 14, 2005 at 09:19:11AM +0200, Joern Nettingsmeier wrote: Joern Nettingsmeier wrote: hi everyone! for those interested in linux audio development, the linux audio conference 2005 (http://lac.zkm.de) at the center for arts and media in karlsruhe/germany will be streamed live in both vorbis and theora formats. since we've got lots and lots of bandwidth to burn on our relay network, can somebody get this on slashdot? bring it on :) I forwarded your post to the DC metro area LUG lists. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: splitting DLE's
On Tue, Apr 12, 2005 at 01:45:15PM +0200, Paul Bijnens wrote: I can't remember if this was mentioned, but what is the amanda version of the client giving the error message? I believe you need 2.4.3 or later to specify a diskname and diskdevice. In 2.4.2 the syntax of a DLE would allow only a diskname. ahha! the client is a debian woody (stable) box with amanda 2.4.2p2-4. That makes perfect sense. Because the diskname should be unique in a disklist file, the workaround in that time was to add mulitple /. to the end of a diskname, like this: some.host.org /my/disknamedumptype-with-excludes some.host.org /my/diskname/. dumptype-with-other-excludes some.host.org /my/diskname/./.dumptype-with-yet-other-excludes That is, is you don't want/can't upgrade the client to a recent amanda version. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
Re: splitting DLE's
On Tue, Apr 12, 2005 at 09:03:16AM -0400, Jon LaBadie wrote: On Tue, Apr 12, 2005 at 01:45:15PM +0200, Paul Bijnens wrote: I believe you need 2.4.3 or later to specify a diskname and diskdevice. In 2.4.2 the syntax of a DLE would allow only a diskname. Because the diskname should be unique in a disklist file, the workaround in that time was to add mulitple /. to the end of a diskname, like this: some.host.org /my/disknamedumptype-with-excludes some.host.org /my/diskname/. dumptype-with-other-excludes some.host.org /my/diskname/./.dumptype-with-yet-other-excludes That is, is you don't want/can't upgrade the client to a recent amanda version. I would not have remembered that on my own, but as soon as you said it I did :) An aside, I've always wondered about the selection of column names there, diskname and diskdevice. Very /sbin/dump and whole-file-system centric. As an alternative, might DLEtag and DataLocation be more descriptive? And the pairing of host and DLEtag be known as the DLEname? Ahh, nevermind, it is just semantics. just semantics, but now I know what is meant. So thanks everyone for discussing this. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact [EMAIL PROTECTED]
