Re: Sound through HDMI with ATI Radeon HD 4550
On Tue, Jan 26, 2010 at 04:06:11PM +0100, deb...@bercot.org wrote: Hello, I'm not sure I'm at the right place (please, if not, tell me where I can find a solution...) but I have a problem with multimedia hardware. So, I've changed my graphic card and I've bought an ATI Radeon HD 4550. My goal is to use only an HDMI cable between my computer and my AV amplifier. I've installed Debian Sid but I can't have any sound... Everything seems OK with Alsa (and PulseAudio), but no sound !!! With google, I've found this : http://www.phoronix.com/scan.php?page=news_itempx=NzgxMA [I should need a 2.6.33 kernel to have HDMI support with ATI cards] So, I've compiled the 2.6.33RC5 kernel, but no difference !!! The card seems to be OK : # aplay -l List of PLAYBACK Hardware Devices card 0: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 Do you have any idea ? This list is mostly not active anymore. You might have more luck on pkg-multimedia-maintainers. I've Cc:'ed that list. (maybe also try debian-user list?) -edrz -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: closing down debian-multimedia alioth project and l.d.o list?
On Sat, Dec 05, 2009 at 10:03:16PM +0800, Paul Wise wrote: On Fri, Dec 4, 2009 at 1:24 PM, Free Ekanayaka fr...@debian.org wrote: |--== On Thu, 3 Dec 2009 13:45:07 -0500, Eric Dantan Rzewnicki e...@zhevny.com said: EDR As mentioned briefly in the IRC meeting today, there is not much to EDR discuss about whether or not to do this. I'm just curious to find out EDR how to go about it. EDR I imagine the list can't go away so long as any packages have EDR debian-multime...@l.d.o in Maintainers: field. EDR As for the alioth project, I guess we need to see which, if any, EDR packages remain to be moved. There are quite a few still: http://qa.debian.org/developer.php?login=debian-multime...@lists.debian.org While I totally agree we should aim to eventually shut it down, I think we can keep this as low priority, that means change the Maintainer field of those packages slowly over the time when they actually need an upload. I'm not active on the team, but I think you should keep both lists. In the Debian Games team we use debian-devel-games for discussion and pkg-games-devel for bugs/etc. I also thought of something similar sometime after starting this thread. Perhaps the l.d.o list could remain as a user help/discussion list and the alioth list be reserved for development discussion. At the moment we mostly have only developer discussions, it seems, but that could perhaps change over time. In any case, it seems there is no need for any immediate change. -edrz -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
closing down debian-multimedia alioth project and l.d.o list?
As mentioned briefly in the IRC meeting today, there is not much to discuss about whether or not to do this. I'm just curious to find out how to go about it. I imagine the list can't go away so long as any packages have debian-multime...@l.d.o in Maintainers: field. As for the alioth project, I guess we need to see which, if any, packages remain to be moved. Anything else? -edrz -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian Multimedia Maintainers irc meeting poll
In case anyone on this list isn't yet subscribed to pkg-multimedia-maintainers on alioth[0] there has been some discussion of starting to have regular irc meetings to coordinate packaging efforts. It's been proposed to have it on #debian-multimedia. There is a doodle poll[1] for choosing a meeting date and time and a page in the wiki for adding agenda items[2]. -edrz [0]: http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers [1]: http://www.doodle.com/thdbg3bykid653ns [2]: http://wiki.debian.org/DebianMultimedia/Meetings -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Fwd: Native Ogg Theora support in Firefox
On Thu, Jul 31, 2008 at 10:41:32PM +0200, Holger Levsen wrote: Hi, FYI :) Pretty exciting and cool indeed, IMO :) Indeed. I'm really glad they got past the patent FUD wrt to theora to make this happpen. One of my post dc8 plans is to set up a server with mdale's metavid stuff as a demo of what can be done with content from DC and other confs I have stores of video data from. Which reminds me, I want to capture cmml of the irc channels for later muxing into the ogg files. -Eric Rz. -- Forwarded Message -- Subject: Native Ogg Theora support in Firefox Date: Thursday 31 July 2008 12:52 From: Planet Xiph: silvia [EMAIL PROTECTED] What a day for great news! [Chris Blizzard][1] and [Chris Double][2] of Mozilla have just announced that native [Ogg Theora and Vorbis][3] support is now available in the trunk of Firefox's codebase. Compiles of that codebase have the support enabled by default, which means that very soon now any Firefox that gets installed on any platform will come with built-in Ogg Theora/Vorbis support out of the box. This is exciting in more than one way. First of all: it is a browser implementation of the new HTML5 video tag currently in the process of standardisation. Opera is the only other browser that has support for the video tag also using Ogg Theora as the baseline codec, but [Opera's support is in an experimental branch][4], while Firefox will be the first to have native support. The choice to include Ogg Theora natively is a huge step forward on Mozilla's behalf considering the [submarine][5] [patent][6] [debate][7] that has been raging around this codec ever since it was removed from the HTML5 specification as baseline codec. So, maybe the Mozilla lawyers believe the risk of this threat is negligible and if they have, other browser vendors may follow. This is a big day for open media technology and a big day for the future of video on the Web. It is important because the availability of free and unencumbered video and audio codecs that are natively supported on the Web will make a huge difference in progressing the capabilities of video on the Web. As an example, look at the efforts of [Annodex][8], where we are creating video webs through a video format with embedded hyperlinks and annotations. To make this feasible, you need a standard and open format for the time-aligned hyperlinks and annotations, which will only work with a flexible open video format. This is just an example: open captioning and karaoke formats, open overlay formats and many other extensions to video formats will now be feasible. The golden age of online video is starting. [ Michael Dale][9]'s [metavid][10] project is giving us a taste of this future. Video can be searched on time-aligned annotations and only the relevant video segment will be retrieved. Video segments can be addressed by [temporal hyperlinks][11] and recombined easily into new mash-ups simply through the creation of a list of temporal hyperlinks. How powerful this will be when we do it across sites! This takes video into a completely new dimension. Now, let's step back again from the future to the current exciting news. I am particularly proud of the input that Annodex people have made to this development - code from people like Conrad Parker, Andre Pang, Zen Kavanagh, Shane Stephens, and many others. Chris Double from Mozilla has been implementing the Firefox Ogg Theora support for more than a year and is using Shane Stephens' [liboggplay][12] library, which was originally developed by [CSIRO][13] and is in the [code repository][14] of the [Annodex Association][15]. liboggplay requires libraries from [Xiph.org][16] (libogg, libvorbis, libtheora) and from [Annodex][8] ([liboggz][17] and [libfishsound][18]) to work. All of this has to work across operating system platforms. It is an enormous achievement and I congratulate the open media technology community on this big success. [1]: http://www.0xdeadbeef.com/weblog/?p=492 [2]: http://www.bluishcoder.co.nz/2008/07/theora-video-backend-for-firefox-landed .html [3]: http://hg.mozilla.org/mozilla-central/index.cgi/rev/20a2f518b07d5896d9392311 b712540b101b53ec [4]: http://ajaxian.com/archives/opera-element-proposal [5]: http://www.bluishcoder.co.nz/2007/12/video-element-and-ogg-theora.html [6]: http://metavid.ucsc.edu/blog/2007/12/11/the-attack-against-ogg-theora-or-how -i-learned-to-stop-worrying-and-love-the-proprietary-web/ [7]: http://blog.gingertech.net/2007/12/13/about-baseline-video-codecs-and-html5/ [8]: http://annodex.net/ [9]: http://metavid.ucsc.edu/blog/2008/07/30/native-theora-for-firefox-31/ [10]: http://metavid.ucsc.edu/ [11]: http://annodex.net/node/69 [12]: http://wiki.xiph.org/index.php/OggPlay [13]: http://ict.csiro.au/ [14]: http://svn.annodex.net/liboggplay/ [15]:
Re: Ardour still not present in testing
On Tue, Jul 22, 2008 at 10:26:52PM -0400, Brandon Simmons wrote: Hello, Has there been any progress in getting any version of ardour into Lenny? Thanks, Brandon Not as far as I know, so no useful info from me. But, I just wanted to note that 2.5 was recently released and might possibly resolve the non-security bugs (maybe, hopefully?) -Eric Rz. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-icecast-devel] backporting icecast and ezstream
On Fri, Jul 18, 2008 at 12:05:29PM +0200, Jonas Smedegaard wrote: On Fri, Jul 18, 2008 at 12:25:50AM -0500, Eric Dantan Rzewnicki wrote: ([EMAIL PROTECTED] and [EMAIL PROTECTED] added to Cc:) On Fri, Jul 18, 2008 at 04:39:07AM +0200, Jonas Smedegaard wrote: On Thu, Jul 17, 2008 at 07:15:13PM -0500, Eric Dantan Rzewnicki wrote: Here you go: deb http://debian.jones.dk/ etch icecast Compiled for i386 and amd64. Tell me if you need other packages backported too. Excellent! thank you very much. I'll test tomorrow with these. Any chance you can get them into backports.org? Your personal apt repo is fine for my personal use and for pre-debconf testing, but I think the debconf server admins want them in bpo if we are to use them for dc8. Sorry - won't do that extra work: * Either a few helper tools needs to be backported (like I've done at http://debian.jones.dk/pkg/src ) or packages needs to be adjusted to use older versions of those helper tools (and tested that it does not cause regressions!) * Backported icecast2 links against backportet libshout. I believe bpo does not allow linking against anything but Etch libraries I fail to see how packages backported and signed by the package maintainer is any worse that bpo (yes, I compile inside chroot but as noted above not entirely clean ones - but I contaminate as least as possible IMHO). No worries. If it's too much pain or just plain against policy, we can have our own small repo for video stuff at dc8. As for other packages ... We need a fixed ffmpeg2theora as I believe the etch version still has #429937: no large file support. I'll have a look at that. I read the bugs more closely, now. I think it's just that it hasn't built on mipsel, plus 0.19 was removed from testing and somehow that messed things up: http://release.debian.org/migration/testing.pl?package=ffmpeg2theora At the moment, the only other thing I can think of is more a would be nice but, not necessary item: libtheora0 in order to take advantage of the faster decoder (which is actually also used by the encoder, iiuc). Compiled now - will rebuild the others to ensure they take advantage of it (although I suspect rebuilding might not be needed as it is a shared library and the so version was not bumped). Excellent. Thank you again for your help. -Eric Rz. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-icecast-devel] backporting icecast and ezstream
On Fri, Jul 18, 2008 at 04:55:43PM +0200, Jonas Smedegaard wrote: On Fri, Jul 18, 2008 at 04:24:14PM +0200, Romain Beauxis wrote: Le Friday 18 July 2008 12:05:29 Jonas Smedegaard, vous avez écrit : Excellent! thank you very much. I'll test tomorrow with these. Any chance you can get them into backports.org? Your personal apt repo is fine for my personal use and for pre-debconf testing, but I think the debconf server admins want them in bpo if we are to use them for dc8. Sorry - won't do that extra work: * Either a few helper tools needs to be backported (like I've done at http://debian.jones.dk/pkg/src ) or packages needs to be adjusted to use older versions of those helper tools (and tested that it does not cause regressions!) * Backported icecast2 links against backportet libshout. I believe bpo does not allow linking against anything but Etch libraries You can link against library from bpo, but you need to be very carefull with the versions, since the build-dep resolver is, ahem..., complicated, and cannot be simulated beforehand... ...which means you don't really know what you've got: Imagine backporting ffmpeg, backporting some packages against that ffmpeg, and then update the ffmpeg backport. Is binNMUs then done automagically? Yes, the problem is similar to main Debian (all packages are built against unstable, not rebuilt when entering testing), but bpo has less eyeballs, I suspect. Oh - and I suspect my example with ffmpeg is a quite valid one: Some cases of undefined img_convert occur at runtime (try install freej in Lenny and then update libav* to the ones from debian-multimedia.org ). I wouldn't wish ffmpeg compilation hell on anyone and certainly am not asking you to go through it for debconf-video's sake. I've never tried building .debs of ffmpeg or dependent apps, but just trying to build ffmpeg2theora for local installation (and trying to find the appropriate + buildable ffmpeg snapshot) has left me quite angry in the past. -Eric Rz. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-icecast-devel] backporting icecast and ezstream
([EMAIL PROTECTED] and [EMAIL PROTECTED] added to Cc:) On Fri, Jul 18, 2008 at 04:39:07AM +0200, Jonas Smedegaard wrote: On Thu, Jul 17, 2008 at 07:15:13PM -0500, Eric Dantan Rzewnicki wrote: Hello icecast packagers. I'm working with the debconf-video team. We will be running everything on etch for DC8, but there are some bugs in the etch icecast version that we ran into last year and ezstream wasn't packaged for etch. So, I was going to try backporting both. It was suggested in our irc meeting today that I contact you, the maintainers, first. I've done some small amount of backporting other packages, but it's been a few years and that was only for local use. Any help or advice you can give me would be much appreciated. If any of you happened to have time to just do it, the video-team would be very happy, of course. But, I'll try to see what I can do on my own tomorrow anyway. Here you go: deb http://debian.jones.dk/ etch icecast Compiled for i386 and amd64. Tell me if you need other packages backported too. Excellent! thank you very much. I'll test tomorrow with these. Any chance you can get them into backports.org? Your personal apt repo is fine for my personal use and for pre-debconf testing, but I think the debconf server admins want them in bpo if we are to use them for dc8. As for other packages ... We need a fixed ffmpeg2theora as I believe the etch version still has #429937: no large file support. The bug was closed with 0.19-1. But, _no_ version is currently in testing due to various issues, unfortunately. So, it would seem this one is not so simple. Maybe we can just apply the lfs fix to the etch version as we did last year. I think the videoteam already has our own package for that. This is only needed on one videoteam box, so I think we probably don't have to have it at bpo. (someone please correct me if I'm wrong.) At the moment, the only other thing I can think of is more a would be nice but, not necessary item: libtheora0 in order to take advantage of the faster decoder (which is actually also used by the encoder, iiuc). Of course this would mean the others mentioned above would need to be built against it, I guess, making more work. Please don't feel obligated to do any more. What you've done is already a big help. We can also ask the pkg-xiph folks for help. But, of course much gratitue will ensue if you can help us out some more. :) Thanks, Eric Rz. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491120: jackd: Can not find the jackstart program
I'm pretty sure jackstart was deprecated a long time ago. It was used before the lsm module, which itself has been replaced by the rt rlimits via pam that you mentioned in your previous mail. On Wed, Jul 16, 2008 at 10:26:00PM +0200, Torquil Macdonald Sørensen wrote: Package: jackd Version: 0.109.2-3 Severity: normal The jackd man page talk of a jackstart program/script, but I can not seem to find it anywhere in Debian. There is even a man page: /usr/share/man/man1/jackstart.1.gz Best regards, Torquil Sørensen -- System Information: Debian Release: lenny/sid APT prefers experimental APT policy: (750, 'experimental'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages jackd depends on: ii libc6 2.7-12 GNU C Library: Shared libraries ii libjack0 0.109.2-3 JACK Audio Connection Kit (librari ii libreadline5 5.2-3 GNU readline and history libraries ii libsndfile1 1.0.17-4 Library for reading/writing audio Versions of packages jackd recommends: ii libpam-modules 0.99.7.1-6+b1 Pluggable Authentication Modules f ii qjackctl 0.3.2-1 User interface for controlling the -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491116: jackd: Unreasonable xrun numbers
Is your issue solved by the recommendation to use 3 periods that you got from the jack list? On Wed, Jul 16, 2008 at 09:06:04PM +0200, Torquil Macdonald Sørensen wrote: Package: jackd Version: 0.109.2-3 Severity: normal After starting jackd with realtime priority, as a non-root user (using the /etc/security/limits.conf trick described in /usr/share/doc/jackd/README.Debian), I get very unreasonable xrun numbers in the Messages log of qjackctl. E.g.: alsa_pcm: xrun of at least 1216234611802.112 msecs That would correspond to a delay of about 33 hours :-) Best regards, Torquil Sørensen -- System Information: Debian Release: lenny/sid APT prefers experimental APT policy: (750, 'experimental'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages jackd depends on: ii libc6 2.7-12 GNU C Library: Shared libraries ii libjack0 0.109.2-3 JACK Audio Connection Kit (librari ii libreadline5 5.2-3 GNU readline and history libraries ii libsndfile1 1.0.17-4 Library for reading/writing audio Versions of packages jackd recommends: ii libpam-modules 0.99.7.1-6+b1 Pluggable Authentication Modules f ii qjackctl 0.3.2-1 User interface for controlling the -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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]
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]
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]
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]
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: 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: 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]
