Re: Release update: transitions status and freeze, RC-bugs
Due to the rate of change in unstable, it's not easy at the moment to accurately estimate when we might be able to freeze. In order to help us keep a clearer picture of which changes still need to occur before we can freeze, we will be introducing a transition freeze before the end of this month. If you have not yet discussed your transition with the Release Team, please ensure that you have done so before May 21st. We do have a pending transition: enable users to be able to switch the installed jack implementation, although we don't intend to actually support more than one. So if we want to do this (and I really think we should), we should discuss this RSN. NB: This mail didn't go to debian-release yet, because I don't consider myself qualified to decide on this plan. Comments are more than welcome! I think we should go for it. The jackd2 package has stabilized with the latest -13 upload, so we're now ready for breaking things again. ;) I guess we can also revive the former jackd1 package, so there would actually be a choice. Who's going to talk to the release team? Ciao -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver Internet nach 1996 ist ohnehin nur noch verkommerzialisierte Scheiße (Christian Anger) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#580618: jack-audio-connection-kit: FTBFS on armel (error: 'mcontext_t' has no member named 'gregs')
On Fri, May 07, 2010 at 09:20:29AM +0100, Adam D. Barratt wrote: Hi, Hi! Unfortunately, j-a-c-k is still failing to build on armel. -9 has been tried three times, two of which resulted in an illegal instruction stopping the build; the other gave: ../dbus/sigsegv.c: In function 'signal_segv': ../dbus/sigsegv.c:107: error: 'mcontext_t' has no member named 'gregs' That's easy to fix. It's another #if !defined(__arm__) fwiw, the HPPA build has also been tried several times yet with no success, but I'm not entirely sure whether those are package or buildd issues. E: Caught signal 'Terminated': terminating immediately during configure looks like a buildd issue to me, though I wouldn't insist on this. ;) I'll also start a hurd VM later to fix the last FTBFS. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#580363: jack-audio-connection-kit: manpages are not generated
Package: jack-audio-connection-kit Severity: minor Hi! The manpage fix doesn't really work: cd: 1: can't cd to man sh: Can't open fill_template This is called from man/wscript, we're obviously in the wrong directory. Since this shell template was only a quick and dirty hack, the bug should best be fixed by decent python code for man/wscript. See http://trac.jackaudio.org/ticket/166 for more information. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#579465: closed by Adrian Knoth a...@drcomp.erfurt.thur.de (Bug#579465: fixed in jack-audio-connection-kit 1.9.5~dfsg-4)
On Wed, May 05, 2010 at 03:38:13PM +0200, Cyril Brulebois wrote: Any chance to get more information what's going on there? Everything is fine on sparc, mips, powerpc, amd64, i386 and s390, so I wonder what could cause compilation on kfreeBSD to die that early. You only check_tool on compilers in the IS_LINUX case. Therefore, no compilers are found. If one tweaks that to check_tool() anyway, many more errors come up. Unfortunately, I don't have time to chase them all. I've installed GNU/kFreeBSD in a virtualbox VM and have exactly figured out the same: Utils.detect_platform() returns 'posix' on kFreeBSD and there's no match on this. I'm working on a patch, especially for the corner cases later. The code doesn't really honour the existence of BSD, yet. ;) Let's see... Thanks -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
[ras...@gmx.de: Bug#512786: audacity recording freezes in 1.3.6-2 to 1.3.12]
Hi! Is it just me or is audacity broken in 9 out of 10 cases? I think it's the most overrated audio application ever, its portaudio is a pure mess, either playback or recording doesn't work as expected, random freezes on various platforms and so on. If I were a company's QA department, I'd completely drop it from my product portfolio. ;) Just my small rant, now back to jackd. ;) - Forwarded message from Ralf Streiber ras...@gmx.de - Date: Tue, 04 May 2010 14:29:16 +0200 From: Ralf Streiber ras...@gmx.de To: 512...@bugs.debian.org Subject: Bug#512786: audacity recording freezes in 1.3.6-2 to 1.3.12 I have still the same problem as in the first report of this thread, now with audacity 1.3.12. Kernel: 2.6.33.2 Debian-Sid 26.04.2010. So I return to audacity 1.3.5 again. Changing the prferences ( bit-rate, frequenz-sample-rate) has no effect. wkauz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers - End forwarded message - -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver Ich denke, also spinn' ich... ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#580089: jack-audio-connection-kit: FTBFS on ia64 and alpha
On Mon, May 03, 2010 at 04:03:10PM +0100, Adam D. Barratt wrote: Hi, Hi! This may have the same root cause as the armel failure, in which case please merge them. I don't think so. For the alpha and ia64, I have written a fix: http://trac.jackaudio.org/attachment/ticket/171/jackd2-pointersize.patch Next upload will hopefully build on these architectures. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#580088: jack-audio-connection-kit: FTBFS on armel (cannot convert 'int' to 'va_list')
On Mon, May 03, 2010 at 04:00:14PM +0100, Adam D. Barratt wrote: ../common/JackAPI.cpp:303: error: cannot convert 'int' to 'va_list' for argument '4' to 'jack_client_t* jack_client_open_aux(const char*, jack_options_t, jack_status_t*, va_list)' The code in question: jack_client_open_aux(client_name, (jack_options_t)options, NULL, NULL); Obviously, arg4 is NULL, so the message means the compiler cannot convert 0 to a va_list, which should be (more or less) a pointer. Or at least was until some va_list mangling in gcc-4.4. I don't have a clue: anybody more common with ARM specifics around? TIA -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#580088: jack-audio-connection-kit: FTBFS on armel (cannot convert 'int' to 'va_list')
On Mon, May 03, 2010 at 05:50:39PM +0100, Simon McVittie wrote: The code in question: jack_client_open_aux(client_name, (jack_options_t)options, NULL, NULL); Instead of trying to fake up an empty va_list, why not call the varargs version, with only the argument terminator in its varargs? jack_client_open(client_name, (jack_options_t)options, NULL, NULL); Absolutely. I've been blind. ;) Thanks, this should work. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#580089: jack-audio-connection-kit: FTBFS on ia64 and alpha
On Mon, May 03, 2010 at 10:07:44PM +0100, Adam D. Barratt wrote: Next upload will hopefully build on these architectures. Nope :-/ They now fail for different reasons. That's good news. I've already checked the build logs for the -5 upload. Alpha was easy to fix, and I did this with -6, so let's see if it's working. ia64: 19:48:32 runner system command - ['/usr/bin/gcc', '-g', '-O2', '-g', '-Wall', '-O2', '-O3', '-Idefault/linux', '-I../linux', '-Idefault/posix', '-I../posix', '-Idefault/dbus', '-I../dbus', '-Idefault', '-I..', '-Idefault/common', '-I../common', '-Idefault/common/jack', '-I../common/jack', '-I/usr/include/dbus-1.0', '-I/usr/lib/dbus-1.0/include', '../dbus/sigsegv.c', '-c', '-o', 'default/dbus/sigsegv_1.o'] ../dbus/sigsegv.c: In function 'signal_segv': ../dbus/sigsegv.c:101: error: 'NGREG' undeclared (first use in this function) I just fetched libc6.1-dev for IA64 and checked the ucontext.h for NGREGs. It's not there, also ../dbus/sigsegv.c:106: error: 'mcontext_t' has no member named 'gregs' is not there, but this makes sense. IA64 has so many registers. I'll simply remove the line in question on IA64, we don't want to print 160 registers or something like this to the user. In other words: I have an idea how to fix this, but I'll have to rely on the buildds in another upload. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#579938: [vlc-plugin-jack] Disconnects between tracks/songs
On Sun, May 02, 2010 at 06:01:09PM +0300, David Baron wrote: I need to connect vlc###-system in the qjackctl connection pane to hear music. At each track playing an audio-CD, for example, it disconnects and I need to reconnect to hear music. Not a desirable behavior! Shouldn't it be sufficient to go to the preference menu, select Show all settings, then choose Audio/Output modules/JACK and say connect to clients matching with or without automatically connect to writable clients? This, once found, works just fine! No need to touch qjackctl at all. Glad it worked. ;) Question is: what should be the default mode when jackd is found running on program start (which would busy up alsa)? I think it should simply play. At worst, auto-connect should be in the simple options and default checked. I expected this proposal, and I think it's wrong. The point is: jack is not a tool for ordinary desktop users but targeted at professional music production. Jack is not supposed to run as a desktop sound server, this is what pulseaudio is for. Consequently, there is no sensible default where to connect. Physical outs? Or some FX-chain in advance? Or no connection at all, because the output will be fed to a streaming server? And BTW: a running jackd doesn't imply that ALSA is busy. Normally, there is a dedicated (separate) professional audio card in a jackd setup that's connected to the studio. And if you run jackd in dummy mode, no soundcard at all would be occupied. BTW: Unless you really need to separate the vlc outputs from all other system outputs, I recommend using the pulseaudio audio plugin instead and then use pulseaudio-module-jack to bridge to jackd. This way, your connections are always on, no need to mess with qjackctl at all. ;) I wish pulse was up to snuff but it is just too troublesome. Someday. You think so? I claim that's FUD. If something isn't working, file a bug report against pulseaudio or the application in question. To me, it works like a charm, vlc, skype, flash, mplayer and the lot all outputting to pulseaudio which then feeds everything to jackd. Way more stable than the libasound2-jackd-alsa bridge. And make sure to try the DBUS interface support in current qjackctl. (setup/Misc-tab). This might be especially useful in your single card setup: with DBUS support, jackd2 (then jackdbus) talks to pulseaudio, and pulseaudio will release the soundcard, so jackd can be started. In other words, pulseaudio and jackd hand over the card to each other. No need to look for and shutdown all the apps that prevent jackd from starting. You should really give it a whirl. I never want to go back. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#579464: Fixed upstream
On Sat, May 01, 2010 at 09:29:08PM +0200, Jonas Smedegaard wrote: If you haven't started yet, I could invest one or two hours updating to latest svn. This fixes almost all issues. I can also do the upload (DM), just let me know. Please do! Done. This was harder than expected. First, it took me some time to understand quilt. I must admit it has some nice features, especially quilt fold was useful. (if somebody could tell me how to get rid of all these modified files after git-buildpackage...) Well, then, the atomic patch was wrong. I have a sparc64 machine and was able to correct it before uploading. Then, there was a second error breaking atomic operations on powerpc. Good that I also have a powerpc machine (PlayStation3 and IBM QS21 CellBlade) to fix this. ;) Finally, the code calls get_cycles() which is more or less hand-written assembler on the well-known targets. And it's missing everywhere else, so I hacked a dummy function. After four hours, I now have a working x86, powerpc and sparc version. Hope the other exotic platforms (kfreebsd, mips, arm, s390) can successfully use my fallbacks. In addition, the session revealed a bug in FFADO on powerpc. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#579464: Fixed upstream
On Sat, May 01, 2010 at 08:28:05PM +0200, Jonas Smedegaard wrote: This got fixed upstream (r3994). We should upgrade to this revision, because it also contains r3993. r3993 is required to compile the jackd2 on non-ALSA platforms. Sounds great. I am too busy to work on this the next couple of days. At the risk of being a pain, do you have an ETA as to when a new upload might be possible? A fixed j-a-c-k would (hopefully) allow us to finally push the entangled celt and directfb transitions in to testing. I still have too little time now, but will try have a short look at it. If you haven't started yet, I could invest one or two hours updating to latest svn. This fixes almost all issues. I can also do the upload (DM), just let me know. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver IKEA: Imitation von Kiefer, Eiche und Ahorn ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd repo merged
On Thu, Apr 29, 2010 at 04:54:43PM +0200, Jonas Smedegaard wrote: I had jackd1 in master/upstream and jackd2 in master.jackd2/upstream.jackd2. Given that we want to re-introduce jackd1, it might be a good idea to fix this (if possible). OTOH, we could create a dedicated jackd1 repo later, too. It is easy to spawn a dedicated jackd1 branch later. Ah, forgot about this. We could branch before the merge, later, absolutely. ;) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver Reset-Knopf? Ich habe kein Windows! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#579464: Here's the patch
Hi!
Like always, I forgot to attach the patch to the mail. ;) Here it is.
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
Mit Apachen ist gut quatschen
diff --git a/linux/JackAtomic_os.h b/linux/JackAtomic_os.h
index b69cb22..c39174d 100644
--- a/linux/JackAtomic_os.h
+++ b/linux/JackAtomic_os.h
@@ -67,6 +67,14 @@ static inline char CAS(volatile UInt32 value, UInt32 newvalue, volatile void* ad
return ret;
}
+#else
+#warning using builtin gcc (version 4.1) atomic
+
+static inline char CAS(volatile uint32_t value, uint32_t newvalue, volatile int32_t* addr)
+{
+return __sync_bool_compare_and_swap (addr, value, newvalue);
+}
+
#endif
#endif
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#579479: jack-audio-connection-kit: FTBFS on powerpc
Package: jack-audio-connection-kit Version: FTBFS on powerpc Severity: normal Tags: sid Hi! According to https://buildd.debian.org/fetch.cgi?pkg=jack-audio-connection- kitarch=powerpcver=1.9.5~dfsg-3stamp=1272311535file=logas=raw jack FTBFS on powerpc. I've already fixed this issue for another project, it's basically another ifdef patch. I don't have the time to do it right now, but I hope I'll have it tomorrow or on Thursday, so just to make sure we won't forget about this issue... -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: DebConf10: Final Call for Contributions!
On Sun, Apr 25, 2010 at 09:17:02AM +0200, Reinhard Tartler wrote: Calling all potential contributors to DebConf10! One more week until the final submission deadline! Okay, so do we want to give a talk or a presentation on what we work on at debconf10? AFAIUI, there is a number of members attending dc10. Absolutely, and I'm willing to contribute. Stuff that's worth mentioning: - presentation of changes to pro-audio, that is, updated ardour with LV2 support, LV2 plugins like calf - audio infrastructure like the arrival of FFADO and jackd2, including pulseaudio integration; perhaps also multiple JACK implementations if we'll be ready until DC10 - jackd realtime permissions via /etc/security/limits.d/audio.conf Is there more to tell? It's hard to recall everything that happened during the last year, but I'm sure you'll have one or the other item to add. Mplayer anybody? ;) My idea is to attend DebCamp and seize this week to prepare the presentation. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on plan B
On Fri, Apr 23, 2010 at 05:52:35PM -0500, Gabriel M. Beddingfield wrote: On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach Note that this is a wiki and the suggestions come from only one person. True, but Nedko (the author of the article) shouldn't be ignored. He is very knowledgeable and respected in the LAD/Jack communities. Furthermore, he is saying the exact same thing that Torben and I have been saying. I mostly agree with the suggested packaging except jackd, jackdbus and jack server library being separate packages. Not that it'd be wrong, but the amount of packages seems unnecessarily high. There are even people who suggest to put everything in a single jackd1/jackd2 package, but we probably don't want to go this far. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - cross-distro coordination
On Fri, Apr 23, 2010 at 01:48:01PM +0200, Reinhard Tartler wrote: * conservative: Stay with jackd1, ignoring jackd2 and tchack. * stubborn: Switch to jackd2, abandoning jackd1 and ignoring tchack. * bold: switch to supporting multiple implementations. You seem to want the stubborn path, because a cross-distro wave have set off. I think adi should decide on this. And AFAIUI, adi has already decided to go with jackd2. Sorry for kicking in late, I'm horribly busy at the moment. Will hopefully change after 2010-04-28 (project deadline). His arguments were pretty convincing that jackd2 was the best implementation for squeeze. Ok guys, after an endless thread of major and minor technical issues, I suggest the following. If you want, consider this suggestion a rule, though I would personally never ever insist on deciding here. Anyway, I've been the most active jackd maintainer recently, so somebody needs to step forward. ;) We instantly switch to jackd2. End of the story. Ok, it's not actually the end of the story, but we first make progress and upload jackd2 to unstable. This way, our worst case scenario is jackd2-only in squeeze. And that's better than jackd1-only. Why? Because torbenh said so. ;) We know that jackd2 is working, and it currently provides the one important feature required for desktop users: pulseaudio integration, so PA and jackd can coexists without major tweaks like ripping off PA, shutting down applications blocking the audio device and the lot. Torben said: If you can only have one implementation, then jackd2 is probably the best. Ok, so somebody will upload jackd2 within one week. This is where the story continues... We *then* try to support multiple jackd packages. I'm pretty sure this will work, we've already outlined all the details, Garbiel and Torben even hacked a prototype within 15 minutes. If we'll be fast enough to get this into squeeze... well, I think it's mainly copy and paste, the actual work is probably no more than one hour for somebody who knows what he's doing (Reinhard, Jonas). - decide on a default implementation jackd2. - allow users to switch and use a non-default implementation Absolutely. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Rosegarden?
On Thu, Apr 22, 2010 at 11:46:35AM +0200, Jonas Smedegaard wrote: Hi fellow multimedia maintainers, Rosegarden needs some love. Speaking of which, there is a rosegarden fork before they switched to QT4: http://www.openoctave.org/ I can't comment on either of the two, but Open Octave seems to be the next big thing in the Linux audio community. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#578750: ITP: kmid -- MIDI/Karaoke player for KDE
On Thu, Apr 22, 2010 at 10:40:54AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: * Package name: kmid Version : 2.2.2 Upstream Author : Pedro Lopez-Cabanillas p...@users.sf.net * URL : http://kde-apps.org/content/show.php/KMid?content=116404 I think that's the right URL: http://kmid2.sourceforge.net/ I've recently been in contact with the author, because we pack his kmidimon in the Debian Multimedia Team. To quote from his mail: By the way: KMidimon 0.7.3 requires Drumstick 0.3.0, which is still bundled in kmidimon's source tarball and statically linked if the shared libraries weren't found at configure time. In the future, when Drumstick matures enough, the library sources will be removed from the source package. Please talk and coordinate if necessary with the maintainers of KMetronome and KMid2, using Drumstick as well. Are there Debian packages for them? With regard to drumstick, he wrote: BTW. I've fixed two problems in Drumstick 0.3.1, released yesterday. Probably any of them would become a bug report for KMidimon 0.7.3: 1. Subscribe/unsubscribe methods from the MidiPort class are using the ALSA function snd_seq_parse_address(), and can't distinguish between two client names starting with the same characters, like KMid and KMidimon. It is not possible to use KMidimon to monitor KMid output. 2. The list of available MIDI input/output ports is cached by drumstick until a broadcasted ALSA event is received marking the cache as dirty. It is possible that a client application like KMidimon shows an outdated list to the user. Both problems have been fixed in drumstick revision 165: http://drumstick.svn.sourceforge.net/viewvc/drumstick?view=revrevision=165 The best solution for a dynamically linked program would be to simply upgrade the drumstick library. But as Debian is distributing a statically compiled KMidimon, please apply preventively a patch before the next KMidimon release. In other words: it's now the right time to package drumstick separately and change the build requirements for kmidimon. Do you mind packaging drumstick? I'm also Cc pkg-multimedia-maintainers, perhaps somebody is interested. Don't know if you do a lot of multimedia stuff, if so, you might want to consider joining our team. ;) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
[...@drcomp.erfurt.thur.de: RFP: tschack -- Another implementation for the JACK api written in C. Supports SMP]
Hi! As requested by Jonas, here's the RFP. - Forwarded message from Adrian Knoth a...@drcomp.erfurt.thur.de - From: Adrian Knoth a...@drcomp.erfurt.thur.de To: Debian Bug Tracking System sub...@bugs.debian.org Subject: RFP: tschack -- Another implementation for the JACK api written in C. Supports SMP Date: Wed, 21 Apr 2010 14:22:02 +0200 Package: wnpp Severity: wishlist * Package name: tschack Version : 0.118.2 (or git) Upstream Author : Torben Hohn torb...@gmx.de * URL : http://hochstrom.endofinternet.org/trac/tschack * License : GPL, LGPL Programming Lang: C Description : Another implementation for the JACK api written in C. Supports SMP - End forwarded message - -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver Der merkt halt, dass das seine muttermilch ist, die gerade übertragen wird. (user während des dd's der root-partition auf den fileserver) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] Free Firewire Audio Drivers (ffado.org) packaging branch, master, updated. debian/2.0.0+svn1806-1-10-ga1a93ce
On Tue, Apr 20, 2010 at 04:46:11PM +0200, Jonas Smedegaard wrote: Include python site-packages for ffado-mixer (Closes: #578499) +debian/tmp/usr/lib/python* support/xdg/ffado.org-ffadomixer.desktop usr/share/applications/ This looks wrong: Python modules should be packaged separately, following Debian Python Policy. We're talking about /usr/lib/python2.5/site-packages/ffado/ and http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-paths says Public Python modules not handled by python-central or python-support must be installed in the system Python modules directory, /usr/lib/pythonX.Y/dist-packages for python2.6 and later, and /usr/lib/pythonX.Y/site-packages for python2.5 and earlier. We could probably call python-support in the rules file, if it's not done automagically by cdbs. ;) In addition, http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html says Python packages are directories containing at least a __init__.py, other modules, extensions and packages (A package in the Python sense is unrelated to a Debian package) From these lines, I don't think we're required to package this very ffado-specific python support module into a separate package, it probably won't make any sense at all. (there is nobody else relying on it) The debconf package also places a debconf.py in site-packages. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
jackd1, jackd2, jackd3, tschack
Hi! Yesterday, somebody digged out Suse's announcement of our coordinated distro approach for switching to jackd2. A lot has happened during the past hours on the mailing lists and via IRC. Basically, the jackd1 camp isn't really happy. And some people think we should really provide a choice which version to use. Foremost, jackd2 shouldn't be considered the successor of jackd1, but an alternative implementation. Think of exim|sendmail|qmail. So what do we have? jackd1 -- stable, containing jack_session (that's something new) tschack -- jackd1 derivative with SMP support, jack_session jackd2 -- C++ reimplementation, SMP, no jack_session yet, but on the horizon, card reservation via DBUS (pulseaudio integration) jackd3 -- upcoming C++ reimplementation of jackd1 If we can only have one jack version in Debian, we probably really use jackd2 now, mostly because of card reservation. However, this would more or less be a version lock-in. Perhaps we should free ourselves and come up with a solution that allows for different jackd implementations in Debian. Other distros can do this, too. ;) We can't make libjack0 virtual, right? Can we put everything into a single package, let's say jackd1 and jackd2, both containing the stuff which is now present in libjack0, libjack-dev and the jackd package itself? And then let them all Provide: jack-audio-connection-kit or something like this. We might even use alternatives. Could this work? If this is too much trouble, we should stick to our jackd2 plans and wait for jackd3 to come. However, there has already been one good result: somebody is coding jack-session for jackd2 now, because if we really move to jackd2, it wouldn't make sense to only have it in jackd1. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd2 in opensuse
On Sat, Apr 10, 2010 at 04:13:40AM -0400, Eric Dantan Rzewnicki wrote: The opensuse jackd maintainer just informed me that he switched from jackd1 to jackd2 on BuildService. OpenSuse 11.3 will follow soon. Looks like we have coordinated acting of distros, here. ;) Cool! Did you hear from fedora maintainers? Only once, he asked me for permission to forward my mail to fedora-devel, but I haven't seen a corresponding thread in the archive, yet. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Fri, Apr 09, 2010 at 08:25:43AM +0200, Reinhard Tartler wrote: /* * NOTE: JACK_WEAK_EXPORT ***MUST*** be used on every function * added to the JACK API after the 0.116.2 release. * * Functions that predate this release are marked with * JACK_WEAK_OPTIONAL_EXPORT which can be defined at compile * time in a variety of ways. The default definition is empty, * so that these symbols get normal linkage. If you wish to * use all JACK symbols with weak linkage, include * jack/weakjack.h before jack.h. */ is there a rationale for this? I can guess some reasons, but certainity would help. 12:22 torbenh3 adi: it provides binary compatibility of an app built against a higher version of jack against a 0.116.2 jack. 12:24 torbenh3 in other words. a session enabled program will not complain if you downgrade to 0.116.2 .. (you just wont have session support) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Tue, Apr 06, 2010 at 07:29:51AM +0200, Reinhard Tartler wrote:
Can someone fluent in C/C++ please look at this? Perhaps you, Adrian,
since you seem most knowledgeable in JACK around here?
I think I qualify.
I'm not sure if I do. ;) Never used the debian symbol files...
Another source of problem is that presence of machine optimization. In
your buildlog I see symbols that indicate sse2 enabled functions. Has
anyone made sure that jackd2 really works on non-sse2 enabled machines?
I haven't checked, yet, but I have a Debian 486 machine around, so I
could try it. ;) Or I disassemble the library and check for SSE
instructions.
As long as nobody is calling -msse2 with the appropriate arch/cpu
definition, no SSE2 enabled code would be compiled.
(JFTR: SSE2 is available on all amd64 platforms)
Adrian, is there a jackd ABI definition?
No.
What symbols are supposed to be exposed by libjack? I suppose only
globals and functions defined in these files are part of this:
/usr/include/jack
/usr/include/jack/intclient.h
/usr/include/jack/jack.h
/usr/include/jack/ringbuffer.h
/usr/include/jack/statistics.h
/usr/include/jack/thread.h
/usr/include/jack/timestamps.h
/usr/include/jack/transport.h
/usr/include/jack/types.h
/usr/include/jack/midiport.h
Exactly. That's the list each client application relies on.
But is there perhaps a more canonical list?
There is doxygen output available:
http://jackaudio.org/files/docs/html/index.html
Don't know if this qualifies as more canonical, but this file also
refers to the above header files as the full API
Moreover, I see some functions marked as JACK_DEPRECATED in jack.h.
Are they still used by applications and does jack2 still provide them?
The deprecated functions are still provided and even used by
jackd{1,2}'s example clients. ;)
This surely needs fixing, but that's upstream's responsibility. I'll
file a ticket and provide some patches.
Is there more I could do?
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
jackd2 in opensuse
Hi! The opensuse jackd maintainer just informed me that he switched from jackd1 to jackd2 on BuildService. OpenSuse 11.3 will follow soon. Looks like we have coordinated acting of distros, here. ;) -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 05:55:52PM -0400, Felipe Sateler wrote: I've looked a bit into the hiding thing... and jack2 seems to export 2 kinds of symbols. It exports weak symbols (the standard API), and exports several other symbols as default visibility. I'm guessing that Have you seen this comment in jack.h? /* * NOTE: JACK_WEAK_EXPORT ***MUST*** be used on every function * added to the JACK API after the 0.116.2 release. * * Functions that predate this release are marked with * JACK_WEAK_OPTIONAL_EXPORT which can be defined at compile * time in a variety of ways. The default definition is empty, * so that these symbols get normal linkage. If you wish to * use all JACK symbols with weak linkage, include * jack/weakjack.h before jack.h. */ HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd2 ready to roll
On Mon, Apr 05, 2010 at 01:03:45AM +0200, Jonas Smedegaard wrote: It seems to me that upstream use SVN, not Git. Is that correct? And how could the packaging version be 1.9.5+svn3977 when apparently the newest SVN commit in upstream trunk is r3968?!? 3977 was the revision shown by svn info by that time. So there might not be a recent commit to trunk, but to other branches incrementing the revision number. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd2 ready to roll
On Mon, Apr 05, 2010 at 01:33:48PM +0200, Jonas Smedegaard wrote: It seems to me that upstream use SVN, not Git. Is that correct? And how could the packaging version be 1.9.5+svn3977 when apparently the newest SVN commit in upstream trunk is r3968?!? 3977 was the revision shown by svn info by that time. So there might not be a recent commit to trunk, but to other branches incrementing the revision number. Please then elaborate: Which branch do you track? And from which (public accessible!) SVN source? From svn info: URL: http://subversion.jackaudio.org/jack/jack2/trunk/jackmp Repository Root: http://subversion.jackaudio.org/jack Repository UUID: 0c269be4-1314-0410-8aa9-9f06e86f4224 Revision: 3978 Last Changed Rev: 3968 Last Changed Date: 2010-03-26 11:12:37 +0100 (Fri, 26 Mar 2010) And there it is: the global revision is 3977+1, last change to the branch in question is your 3968. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd2 ready to roll
On Mon, Apr 05, 2010 at 01:57:44PM +0200, Jonas Smedegaard wrote: Above means that you did in fact track the standard public accessible trunk branch, and the most recent commit to that branch was not 3978 but 3968 - that other number is simply the global counter of the SVN repository. Right. In other words: r3968 and r3978 of the trunk branch are identical. Right? Absolutely. Ciao -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd2 ready to roll
On Fri, Apr 02, 2010 at 01:30:21AM +0200, Jonas Smedegaard wrote: Hi! Is it ok with you that I repackage from the current vcs-tarball to pristine-(or-repackaged)-tarball + vcs-patch? I'm not sure if I'm qualified to give an answer that respects all implications of this question. I also don't understand half of the quilt-gbp discussion, so I have to rely on the assumption that you know what you're doing. ;) In other words: if you say that tarball+vcs-patch is the right way to address all the copyright issues in the jackd2 package, then go ahead. jackd2-1.9.6 will probably contain most of the things we need, that is, ffado port naming and manpages. ;) Could give a little hint how to repackage/strip new upstream versions, so more than one person in the team knows how to do it? ;) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Real-life meeting
On Thu, Apr 01, 2010 at 09:42:59AM +0200, Fabian Greffrath wrote: I am from Germany (Rurhgebiet). Germany, Jena. (pretty much in the middle) -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
jackd2 ready to roll
Hi! Ok guys, I've fixed the ffado portnaming issue and I also provided the manpages, in other words, the jackd2 package is now ready to be uploaded to *unstable*. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour and the Squeeze Freeze
On Thu, Apr 01, 2010 at 01:22:36PM -0700, i...@bandshed.net wrote: Hi, Hi! Is there still time if Ardour 2.8.8 materializes in the next week or two? Yes, absolutely. As soon as you see ardour-2.8.8, either mail me or file a bug report against the ardour package. I'll surely find the time to update the pacakge. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd2 ready to roll
On Thu, Apr 01, 2010 at 09:53:19PM +0200, Jonas Smedegaard wrote:
Using the separately packaged waf version 1.5.10 fails to locate expat
and libsamplerate (and possibly other system libraries).
Though I don't know waf, I just figured it out, and like always, it's
completely non-obvious:
-conf.env.append_unique('CXXFLAGS', '-O3 -Wall')
-conf.env.append_unique('CCFLAGS', '-O3 -Wall')
+conf.env.append_unique('CXXFLAGS', -O3)
+conf.env.append_unique('CCFLAGS', -O3)
This makes it work, at least until the next error. I'll dig further.
In short: I would very much like to volunteer to repackage the current
vcs-tarball as pristine-tarball + vcs-patch. Is that acceptable?
Different approach: make us the jackd2 repository. ;) So we simply use
git, wildly patch whatever we want, no need to wait for upstream to
apply my patches and pull from their svn repo from time to time. ;)
This way, we can ship the extracted (and checked) waf code, strip *.dll
from the package and all the other tweaks that will be required.
Might sound completely crazy, probably because it isi, but it surely has
its advantages... ;)
Cheerio
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd2 ready to roll
On Thu, Apr 01, 2010 at 11:00:18PM +0200, Adrian Knoth wrote:
-conf.env.append_unique('CXXFLAGS', '-O3 -Wall')
-conf.env.append_unique('CCFLAGS', '-O3 -Wall')
+conf.env.append_unique('CXXFLAGS', -O3)
+conf.env.append_unique('CCFLAGS', -O3)
This makes it work, at least until the next error. I'll dig further.
I guess we could propose the following patch to upstream:
-conf.env.append_unique('CXXFLAGS', '-O3 -Wall')
-conf.env.append_unique('CCFLAGS', '-O3 -Wall')
+conf.env.append_unique('CXXFLAGS', [-O3, -Wall])
+conf.env.append_unique('CCFLAGS', [-O3, -Wall])
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
The trouble with being punctual is that nobody's there to appreciate it.
-- Franklin P. Jones
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd2 ready to roll
On Thu, Apr 01, 2010 at 09:53:19PM +0200, Jonas Smedegaard wrote:
New release uses waf as build system.
So, after perhaps 3hrs of hacking, I now have a patch that enables the
use of system-wide waf. Find attached.
However, the system-wide waf is going to be removed from Debian:
http://www.mail-archive.com/debian-de...@lists.debian.org/msg281401.html
Upstream also discourages system-wide waf:
http://freehackers.org/~tnagy/wafbook/single.html#_installing_waf_on_a_system
01:17 ita adi_: do not trust the distributions - use your version of
waf and redistribute your code with that version - it will save you a
lot of time
01:20 ita adi_: waf is like a configure script, it should not be
packaged - never
Though I understand your concern, I could perfectly live with the
shipped waf. But what do I know? ;)
Cheerio
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
diff --git a/common/wscript b/common/wscript
index da3ab93..ba2440b 100644
--- a/common/wscript
+++ b/common/wscript
@@ -64,7 +64,7 @@ def build(bld):
'JackEngineProfiling.cpp',
]
-includes = ['.', './jack', '..']
+includes = ['.', './jack', '..', '../build/default']
uselib = [PTHREAD]
if bld.env['IS_LINUX']:
diff --git a/example-clients/wscript b/example-clients/wscript
index 4cf08d1..2643b5a 100644
--- a/example-clients/wscript
+++ b/example-clients/wscript
@@ -61,7 +61,7 @@ def configure(conf):
def build(bld):
if bld.env['IS_LINUX']:
-os_incdir = ['../linux', '../posix']
+os_incdir = ['../linux', '../posix', '../build/default']
if bld.env['IS_MACOSX']:
os_incdir = ['../macosx', '../posix']
if bld.env['IS_SUN']:
diff --git a/linux/wscript b/linux/wscript
index 869985d..93957e3 100644
--- a/linux/wscript
+++ b/linux/wscript
@@ -19,7 +19,7 @@ def create_jack_driver_obj(bld, target, sources, uselib = None):
driver.features.append('cc')
driver.env['shlib_PATTERN'] = 'jack_%s.so'
driver.defines = ['HAVE_CONFIG_H','SERVER_SIDE', 'HAVE_PPOLL']
-driver.includes = ['.', '../linux', '../posix', '../common', '../common/jack', '../dbus']
+driver.includes = ['.', '../linux', '../posix', '../common', '../common/jack', '../dbus', '../build/default']
driver.target = target
driver.source = sources
driver.install_path = '${ADDON_DIR}/'
@@ -31,7 +31,8 @@ def create_jack_driver_obj(bld, target, sources, uselib = None):
def build(bld):
if bld.env['BUILD_JACKD'] == True:
jackd = bld.new_task_gen('cxx', 'program')
-jackd.includes = ['../linux', '../posix', '../common/jack', '../common', '../dbus']
+jackd.features='cc cxx cprogram'
+jackd.includes = ['../linux', '../posix', '../common/jack', '../common', '../dbus', '../build/default']
jackd.defines = 'HAVE_CONFIG_H'
jackd.source = ['../common/Jackdmp.cpp']
if bld.env['IS_LINUX'] and bld.env['BUILD_JACKDBUS']:
diff --git a/waf b/waf
index f0f7f63..cd561b6 100755
Binary files a/waf and b/waf differ
diff --git a/wscript b/wscript
index bc88c49..da75181 100644
--- a/wscript
+++ b/wscript
@@ -107,8 +107,8 @@ def configure(conf):
# conf.check_tool('compiler_cxx')
# conf.check_tool('compiler_cc')
-conf.env.append_unique('CXXFLAGS', '-O3 -Wall')
-conf.env.append_unique('CCFLAGS', '-O3 -Wall')
+conf.env.append_unique('CXXFLAGS', [-O3, -Wall])
+conf.env.append_unique('CCFLAGS', [-O3, -Wall])
conf.sub_config('common')
if conf.env['IS_LINUX']:
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Real-life meeting
Hi! A while ago, there was a proposal for a real-life team meeting. In the end, we decided to have IRC meetings, first. If you think it's worth to have a real-life session, then it's probably a good idea to meet before releasing squeeze. AFAIK, Debian will sponsor food, accommodation and travelling for such a team meeting. Who's interested? Proposals for time and place? -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jack-audio-connection-kit_1.9.5-1_i386.changes REJECTED
On Wed, Mar 24, 2010 at 04:26:01PM +0100, Free Ekanayaka wrote: Hi, Hi! So, my opinion is that we should definitely have jack2 in squeeze, because it seems to be better (that is more features, and as stable as jack1) and apparently is what the upstream recommends as well. FWIW I've been using it daily for nearly one year, and also used for a few production projects. Adrian, what's your take at this point? I guess as far as jack is concerned you're one of the most knowledgeable among us. I completely agree with you: it has more features, it is stable, and I'm also using it instead of jackd1. If you don't fear the lack of Debian-wide testing, go ahead and upload 1.9.5 to unstable. The users would probably appreciate this. I see three open issues: * FFADO port naming needs to be redone. Upstream issue, I'll take care. * copy manpages from jackd1 package to jackd2. Anybody can do this. ;) * audio.conf handling. Right now, it cannot be tweaked by the user. Sure it can, but the package will overwrite it on updates. Though this will be fine in almost all cases (we provide a sensible default), it's clearly a policy violation. In the git repo, I have a dpkg approach, but that's inferior to ucf. If somebody with lots of conffile experience is around, feel free to implement it correctly. ;) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jack-audio-connection-kit_1.9.5-1_i386.changes REJECTED
On Wed, Mar 24, 2010 at 12:34:07PM -0300, Felipe Sateler wrote: [jackd2 over jackd1] jack1) and apparently is what the upstream recommends as well. I see no such thing on their webpage, nor in their mailing list (although I don't pay that much attention there). This was also new to me. I never came across such a recommendation. Maybe asking upstream is a good idea. I already did, the answer was: Huu, this is a political question. Which in turn means: technically speaking, it's fine to use either of the versions. Ciao -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jack-audio-connection-kit_1.9.5-1_i386.changes REJECTED
On Tue, Mar 23, 2010 at 11:30:56PM +0100, Free Ekanayaka wrote: AA Reject Reasons: AA Source package jack-audio-connection-kit does not have 'DM-Upload-Allowed: yes' in its most recent version (1.9.4+svn3842-2) I can sponsor this upload to experimental. However I'm wondering if we should rather upload 1.9.4+svn3842-2 to unstable at this point. Why 1.9.4+something and not 1.9.5? I'd like to sort out the config file issue (dpkg vs. ucf), but we could probably upload d2c23abd119cdf7f40654fa443e2a51cf6265893, that is, before I touched the (re-)generation of audio.conf We currently only have one version of this file shipped to the user, so we're talking about one MD5 sum and a second one for our new version if we lower the rt-priority from 99 to 95. This seems a good idea to me, because there's no need for highest rt prios, they should be left to watchdogs which will kill rt processes if they hook up all cpu time. Though modern kernels never grant all cpu time to rt kernels anymore, it's just not necessary to run audio stuff at rtprio 95. jackd usually runs at 10. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver NTSC: Never the same colour ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bits from the Release Team: What should go into squeeze?
On Thu, Mar 18, 2010 at 02:24:49AM +0100, David Henningsson wrote: On the other hand, for casual use of jack, a more stable version would be preferred over a more featureful one. Unfortunately, this is only half of the story. For the occasional use of jack, jackd2 is easier to use, because it can suspend pulseaudio. Let me add a third half to the story then :-) Lennart (as in the PulseAudio developer) came up with an idea of reserving / letting go of audio devices via calls over D-Bus. This is not implemented in jack1. I haven't tested jackd2, but I believe it is implemented there. I don't think any of them actually *suspends* PulseAudio. This is what I was talking about. It's device reservation via D-Bus, and it requires jackdbus from the jackd2 package to work. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bits from the Release Team: What should go into squeeze?
On Wed, Mar 17, 2010 at 02:42:04PM +0100, Reinhard Tartler wrote: Hi! How is the state of affairs wrt jack? If we want jack2 for squeeze, we should communicate this ASAP! Let's put it this way: we know that jackd1 is stable, so it qualifies for a release. If we vote against jackd2, we're missing SMP enabled audio processing and jackdbus. Nothing really important, but users might want to use it in a few months, e.g. for ladish. If we go for jackd2, I still have to push some FFADO changes to jackd2's firewire backend and fix the manpage issue. Simple stuff, one hour of work. I don't have strong feelings for either version. From the amount of testing, I'd vote for jackd1, from a feature perspective, I'd go for jackd2. So whoever is concerned, please share your opinion. ;) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bits from the Release Team: What should go into squeeze?
On Wed, Mar 17, 2010 at 03:23:11PM +0100, Reinhard Tartler wrote: From the amount of testing, I'd vote for jackd1, from a feature perspective, I'd go for jackd2. So whoever is concerned, please share your opinion. ;) What are other distros doing? What are the plans for fedora, gentoo and opensuse? Fedora-Devel has 0.118, so jackd1. CCRMA (Fedora's pro-audio derivative) uses jackd2. Gentoo has jackd1, Gentoo's pro-audio overlay has jackd2. Opensuse has jackd1. I have absolutely no idea about their plans. ;) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
[pk...@debian.org: Bits from the Release Team: What should go into squeeze?]
Hi! Do we want to complete a transition for squeeze? I remember something about libjack0.100. I guess it's also time to decide whether we want jackd2 in squeeze or not. Cheerio - Forwarded message from Philipp Kern pk...@debian.org - Date: Sun, 14 Mar 2010 21:42:58 +0100 From: Philipp Kern pk...@debian.org To: debian-devel-annou...@lists.debian.org Subject: Bits from the Release Team: What should go into squeeze? Dear fellow developers, we all want to get out squeeze as soon as possible. Currently we are still at 400 bugs concerning the next stable release, with 300 of them not yet fixed in unstable. We would like to know what needs attention, what bugs still need to be fixed in your package before squeeze is released, which features or new upstream versions you want to see in squeeze which are not ready yet. Furthermore we would like to get an overview of the remaining transitions that need to be done. It would be great if every team on track could send us a short mail to debian-rele...@lists.debian.org and if every team that still faces work could write up a corresponding bug report filed against release.debian.org, preferably with proper blocked by[1] annotations if bugs are filed for the issues at hand. Like this our progress is publically trackable, maybe even motivating besides the high RC bug count. Please file the bugs at normal severity, the Release Team will prioritise them afterwards. If you think that your package is not ready for squeeze yet, please document that in a RC bug against your package and file a bug for removal from testing against release.debian.org. Of course it will trickle in by itself as soon as all RC bugs are closed and we are not in freeze yet. Some documentation about filing bugs against release.debian.org[2], especially about the usertags used on that pseudo-package could be found on [3]. If in doubt just file the bug and we will tag it accordingly. Core components ~~ From a current point of view squeeze will release with kernel 2.6.32, eglibc 2.11, Python 2.6, X11R7.5, Gnome 2.30, qt 4.6 and KDE 4.4. Transitions we already know about * eglibc 2.11 needs uploading to unstable. * The python, liblo, opencv and imagemagick transitions are currently worked on. * The mpi-defaults, directfb, parted, boost and qt4.6 transitions are queued up afterwards. * Migration of the graphical installer from directfb to Xorg. Kind regards and thanks for your attention, Philipp Kern for the Debian Release Team [1] http://www.debian.org/Bugs/server-control#block [2] http://bugs.debian.org/release.debian.org [3] http://lists.debian.org/debian-devel-announce/2009/09/msg5.html - End forwarded message - -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver Der Computer ist die Antwort, doch was war eigentlich die Frage? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-24-g6b0dbd2
On Tue, Mar 02, 2010 at 03:00:56PM +0100, Jonas Smedegaard wrote:
From a quick glance it looks to me that you are moving around a conffile
in a packaging script. It is tricky to do so properly - an example of
what might else happen is users getting confusing questions if they want
to preserve or overwrite their changes at package update.
Right.
When switching from non-confile to conffile (which seems to be the case
here) there are (complex) ways to handle that properly by using ucf
instead and hashing the older default config files.
What do you think about the attached patch? Is it worth the effort or
should we just simply stick to the dpkg way?
Cheerio
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
From c129122e92feaafce44aebcf2571e5daee918c0c Mon Sep 17 00:00:00 2001
From: Adrian Knoth a...@drcomp.erfurt.thur.de
Date: Mon, 8 Mar 2010 20:56:16 +0100
Subject: [PATCH] Switch to ucf.
Jonas suggested to use ucf instead of dpkg for audio.conf
---
debian/jackd.examples |1 +
debian/jackd.install |1 -
debian/jackd.postinst |2 +-
debian/jackd.postrm |1 +
4 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/debian/jackd.examples b/debian/jackd.examples
index 87bfe17..6c6b2a4 100644
--- a/debian/jackd.examples
+++ b/debian/jackd.examples
@@ -1 +1,2 @@
debian/asound.rc
+debian/audio.conf
diff --git a/debian/jackd.install b/debian/jackd.install
index c4b2175..5db77be 100644
--- a/debian/jackd.install
+++ b/debian/jackd.install
@@ -1,4 +1,3 @@
debian/tmp/usr/bin/jack*
debian/tmp/usr/share/*
debian/bash_completion.d etc
-debian/audio.conf etc/security/limits.d
diff --git a/debian/jackd.postinst b/debian/jackd.postinst
index 6cb11b5..9726539 100644
--- a/debian/jackd.postinst
+++ b/debian/jackd.postinst
@@ -7,7 +7,7 @@ CONFIG_FILE=/etc/security/limits.d/audio.conf
db_get jackd/tweak_rt_limits
if [ $RET = true ]; then
-mv ${CONFIG_FILE}.disabled ${CONFIG_FILE} || true
+ucf --debconf-ok /usr/share/doc/jackd/examples/audio.conf /etc/security/limits.d/audio.conf
else
# user doesn't want RT prio
mv $CONFIG_FILE ${CONFIG_FILE}.disabled || true
diff --git a/debian/jackd.postrm b/debian/jackd.postrm
index 605917c..9bfd3fd 100644
--- a/debian/jackd.postrm
+++ b/debian/jackd.postrm
@@ -7,6 +7,7 @@ if [ $1 = purge ]
then
if [ -e $CONFIG_FILE ]
then
+ucf --purge /etc/security/limits.d/audio.conf
rm $CONFIG_FILE
fi
--
1.7.0
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-24-g6b0dbd2
On Mon, Mar 01, 2010 at 07:42:25PM -0300, Felipe Sateler wrote:
+ mv $CONFIG_FILE{,.disabled} || true
Note that the {,} idiom is a bashism. It will fail with dash as /bin/sh
Thanks, that's fixed.
Adrbetter run checkbashisms next timeian
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd-1.9.5 and jackd2 transition
On Tue, Feb 16, 2010 at 04:16:48AM +0100, Jonas Smedegaard wrote: [jackd-1.9.5] From brief testing: It seems jackd v2 is less flexible in referencing ALSA devices. Confirmed by upstream. I also saw this. This works: jackd -d alsa --device=hw:0,3 Yep. Also, killing jac_netsource spews the following to the console (unlike v1 which just in a single line informed that it was killed): *** glibc detected *** jack_netsource: double free or corruption (!prev): 0x08580810 *** === Backtrace: = /lib/i686/cmov/libc.so.6[0xb7dac824] Can't confirm that. Over here, it looks like this: a...@hex:~$ jack_netsource -H localhost Connected :-) netjack: at frame 93 - total netxruns 1 (1%) queue time= 42669 ^c...@hex:~$ Tested with jackd -d netone. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] calf audio plugins packaging branch, master, updated. upstream/0.0.18.5-52-g6387a5c
On Tue, Feb 16, 2010 at 09:18:51AM +0100, Jonas Smedegaard wrote: Now that you've seen the horrors/wonders I have done to calf and Hydrogen, would you mind me similarly tightening JACK? I would like to add same snippets and use them to more strictly maintain build-dependencies and licensing hints. If you think it's worth the effort, go ahead. ;) Ciao -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
jackd-1.9.5 and jackd2 transition
Hi! I just merged the jackd-1.9.5 release into our repo. I also enabled the jackdbus feature which is required for ladish. If you like, please give it a whirl: http://git.debian.org/?p=pkg-multimedia/jack-audio-connection-kit.git;a=summary To me, it gives better results than jackd-0.118.x. Better here means: pulseaudio runs fine on top of jackd2, way more stable than with jackd1. It supports glitch-free graph updates (start with -S), this means, the audio stream isn't interrupted when you add a new jack client or track in ardour. To my knowledge, there's only one drawback: http://subversion.ffado.org/ticket/264 jackd2 might cause lots of error messages when there's a buffer underrun in FFADO, that is, when the firewire ISO streaming interrupts. With jackd1, you get exactly one underrun message, with jackd2, your terminal might get flooded, which in turn could make the system unresponsive. Since I'm also affected by this behaviour, I'll ping upstream to fix it. What's missing? Manpages. jackd2 doesn't ship them, so I'll copy them from jackd1. I'll also propose to include them in the official jackd2 release. I guess we shouldn't let jackd2 enter unstable without manpages. Remaining question: Do you think jackd-1.9.5 should be included in squeeze? It surely has a lot of benefits, and given the lifespan of a release, having jackdbus in squeeze would easy backporting ladish. OTOH, we currently don't have user feedback, IOW, it lacks testing. Possible solution: upload jackd2 to unstable instead of experimental (which means no way back to jackd1), file a RC bug against the package to prevent it from entering testing, and once we see that users are fine with it, let it slip into squeeze/testing before the freeze. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: I wanna join your team
On Sat, Feb 06, 2010 at 03:29:41PM +0100, Jonas Smedegaard wrote: Hi, Hi! I want to join this team - if you will have me :-) Very much, and welcome to the team. I have been a Debian developer for nearly 10 years, working on a wide Speaking of which: do you mind checking and sponsoring (if acceptable) http://git.debian.org/?p=pkg-multimedia/calf.git;a=summary I've runtime-tested it a lot over the last six month. We shouldn't ship squeeze without calf, the must-have plugin collection for audio production. (ardour+calf is to audio what LAMP is to the web guys). Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver Once you're done, blog your changeset, twitter your blog post, then post the twitter status as a Facebook link and ping me on IM to let me know. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: I wanna join your team
On Thu, Feb 11, 2010 at 12:14:06PM +0100, Jonas Smedegaard wrote: I am brand new in this team, so correct me if I'm wrong, but generally in Debian the term sponsoring is inaccurate here: We do teamwork and those in the team being DDs or DMs upload. Sponsoring is for independent non-DD/non-DM seeking someone to upload without teamwork. Yep, you're right. It's all about uploading. ;) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver I haven't lost my mind; it's backed up on tape somewhere! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] calf audio plugins packaging branch, master, updated. upstream/0.0.18.5-52-g6387a5c
On Thu, Feb 11, 2010 at 01:43:40PM +0100, Reinhard Tartler wrote: perhaps it makes sense to (temporarily) disable the postcommit hook for the calf package, at least until this cdbs black magic stuff has settled? I don't think so. I'd like to see what happens to my package. ;) Deleting the commit messages is a matter of seconds in almost every MUA. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour 2.8.5 Source and librasqal2
On Mon, Jan 25, 2010 at 04:17:29AM -0800, i...@bandshed.net wrote: Hi again, Hi! Don't get too comfortable...didn't know if this would interest you: http://www.ardour.org/releases it's just for for people who want to build with VST support but it is a higher version number, thought I'd pass it along. Thanks, I've imported it into my git repo and building it in pbuilder now. I'll push it after testing it. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#565860: still exists in 0.4.4-2
On Sun, Jan 24, 2010 at 01:58:08PM +0100, Alessio Treglia wrote: Couldn't you just change the Build-Depends from libasound2-dev to libasound2-dev [linux-any]? +1 Seems the right way. ...but it doesn't work on my amd64 chroot, the build fails due to unmet deps. Should I set libasound2-dev [!kfreebsd-amd64 !kfreebsd-i386] instead of libasound2-dev [linux-any]? That's what I do for jackd: libasound2-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
[rn...@rncbc.org: [LAD] [ANN] Qtractor 0.4.5 - A Friskier Demivierge is out!]
Hi! So we can finally drop the local fix, because upstream now ships it. - Forwarded message from Rui Nuno Capela rn...@rncbc.org - Date: Sat, 23 Jan 2010 17:44:31 + From: Rui Nuno Capela rn...@rncbc.org To: linux-audio-...@lists.linuxaudio.org Subject: [LAD] [ANN] Qtractor 0.4.5 - A Friskier Demivierge is out! SCNR ;) mostly yet another bug-fix-regression dot release, nuff said. Qtractor 0.4.5 (friskier demivierge) is out! Change-log: - Changing loop points while playback is rolling, with the play-head any near, was leaving audio clips out-of-sync./li - MIDI event list view was missing some selected items with the very same onset time, now fixed./li - When failing to detect a SSE enabled build, the CFLAGS variables are now properly restored to their previous sane state, preventing all subsequent dependency tests from false positives (bug# 565...@bugs.debian.org)./li - MIDI clip editor (aka piano-roll) multiple selection has been fixed (again) re. move/paste-snapping consistency./li Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball: http://downloads.sourceforge.net/qtractor/qtractor-0.4.5.tar.gz - source package (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.5-3.rncbc.suse112.src.rpm - binary packages (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.5-3.rncbc.suse112.i586.rpm http://downloads.sourceforge.net/qtractor/qtractor-0.4.5-3.rncbc.suse112.x86_64.rpm - binary packages (Ubuntu 8.04 LTS; no LV2 support): http://downloads.sourceforge.net/qtractor/qtractor_0.4.5-1.rncbc.ubuntu804_i386.deb http://downloads.sourceforge.net/qtractor/qtractor_0.4.5-1.rncbc.ubuntu804_amd64.deb - binary packages (Ubuntu 9.10; UPDATED): http://downloads.sourceforge.net/qtractor/qtractor_0.4.5-1.rncbc.ubuntu910_i386.deb http://downloads.sourceforge.net/qtractor/qtractor_0.4.5-1.rncbc.ubuntu910_amd64.deb - user manual (ever still outdated): http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf Weblog (upstream support): http://www.rncbc.org License: Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Cheers Enjoy. -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ Linux-audio-dev mailing list linux-audio-...@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev - End forwarded message - -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver Paradox ist, wenn ein Ochse eine Kuh anstiert. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#565860: FTBFS - configure: error: JACK library not found
On Mon, Jan 18, 2010 at 08:42:24PM -0700, dann frazier wrote: Hi! (just some notes to speed up debugging) configure:4272: checking for SSE optimization configure:4312: g++ -o conftest -g -O2 -msse -mfpmath=sse -ffast-math -I/usr/share/qt4/include -I/usr/local/include -I/usr/include -I/usr/include/qt4 conftest.cpp -L/usr/local/lib -L/usr/lib 5 cc1plus: error: unrecognized command line option -msse cc1plus: error: unrecognized command line option -mfpmath=sse configure:4316: $? = 1 So no SSE on these machines. However: configure:4537: g++ -o conftest -g -O2 -msse -mfpmath=sse -ffast-math -I/usr/share/qt4/include -I/usr/local/include -I/usr/include -I/usr/include/qt4 conftest.cpp -lm -L/usr/local/lib -L/usr/lib 5 cc1plus: error: unrecognized command line option -msse cc1plus: error: unrecognized command line option -mfpmath=sse configure is trying with SSE again. configure:4577: checking for main in -lX11 configure:4606: g++ -o conftest -g -O2 -msse -mfpmath=sse -ffast-math -I/usr/share/qt4/include -I/usr/local/include -I/usr/include -I/usr/include/qt4 conftest.cpp -lX11 -L/usr/local/lib -L/usr/lib 5 cc1plus: error: unrecognized command line option -msse cc1plus: error: unrecognized command line option -mfpmath=sse Again. configure:4634: result: no configure:4646: checking for main in -lXext configure:4675: g++ -o conftest -g -O2 -msse -mfpmath=sse -ffast-math -I/usr/share/qt4/include -I/usr/local/include -I/usr/include -I/usr/include/qt4 conftest.cpp -lXext -L/usr/local/lib -L/usr/lib 5 cc1plus: error: unrecognized command line option -msse cc1plus: error: unrecognized command line option -mfpmath=sse Again. configure:4716: checking for round in -lm configure:4751: g++ -o conftest -g -O2 -msse -mfpmath=sse -ffast-math -I/usr/share/qt4/include -I/usr/local/include -I/usr/include -I/usr/include/qt4 conftest.cpp -lm -L/usr/local/lib -L/usr/lib 5 cc1plus: error: unrecognized command line option -msse cc1plus: error: unrecognized command line option -mfpmath=sse Again. configure:4796: checking for main in -ljack configure:4825: g++ -o conftest -g -O2 -msse -mfpmath=sse -ffast-math -I/usr/share/qt4/include -I/usr/local/include -I/usr/include -I/usr/include/qt4 conftest.cpp -ljack -L/usr/local/lib -L/usr/lib 5 cc1plus: error: unrecognized command line option -msse cc1plus: error: unrecognized command line option -mfpmath=sse Again. configure:4853: result: no configure:4862: error: JACK library not found. And that's it. It's probably a bug in configure(.ac), however, you can work around if you conditionally set --disable-sse on non-amd64. (i386 doesn't have SSE, i686 could, but that's not an ordinary Debian target) HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#565860: still exists in 0.4.4-2
On Tue, Jan 19, 2010 at 09:10:33AM -0700, dann frazier wrote: Hi, especially Alessio! This issue persists with 0.4.4-2. The patch was against configure.ac. I don't know if the minimal debian/rules is sufficient to re-generate configure after applying this patch. If need be, add a line like autoreconf -f somewhere before calling configure. The above is all wrong if configure already gets regenerated by quilt. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#565342: newly released libffado2-based jackd fails with firewire ERR: Could not start streaming threads: -1
On Sat, Jan 16, 2010 at 05:20:03PM +0100, Jonas Smedegaard wrote:
Hi!
If need be, file a ticket at subversion.ffado.org
I guess it makes sense to first try isolate which part of the Debian
packaging system cause problem before passing it upstream:
That's a good idea. Thanks for your comprehensive tests.
Results using *jack* 0.118+svn3796-1, *ffado* 2.0~rc2+svn1569-2 and
*freebob* 1.0.11-1 (i.e. latest Debian Sid except jackd and least
possible dependencies rolled back to latest Debian Squeeze):
OK: firewire-ohci + jackd -d firewire -p 512 -n3 -r 44100 -v5
OK: dv1394 + raw1394 + jackd -d firewire -p 512 -n3 -r 44100 -v5
OK: dv1394 + raw1394 + jackd -d freebob -p 512 -n3 -r 44100
So to sum this up: ffado-2.0~rc2+svn1569-2 gives good results. Freebob
doesn't matter here, and I'd for now say that jackd version doesn't
matter, but we'll soon find out...
Above makes me assume that hardware (MacBook) is ok.
I would say so, yes.
Results using *jack* 0.118+svn3796-2, *ffado* 2.0.0-1 and no *freebob*
OK: dv1394 + raw1394 + jackd -d firewire -p 512 -n3 -r 44100 -v5
FAIL: firewire-ohci + jackd -d firewire -p 512 -n3 -r 44100 -v5
That's interesting. It would indicate that ffado itself is fine, and
it's somehow a question between ffado and the new stack in this
particular version.
There has been a small update to FFADO to make it run on Juju stacks,
however, your tests with the rc2+svn1569 indicate that it has been
(somehow) working before.
I checked
http://subversion.ffado.org/ticket/240
and it looks like the FFADO-on-Juju fixes never got applied to the 2.0.0
release branch.
Any chance you can rebuild libffado from source and apply a patch,
first?
I'm thinking of:
# apt-get source libffado
# apt-get build-dep libffado
$ cd libffado-*
$ patch -p1 /path/to/ffado-2.0.0.patch
$ debuild
$ sudo debi
I've attached ffado-2.0.0.patch to this mail. I guess this could make
ffado work on Juju. If so, I'll take care that this patch gets applied
upstream and that we get another release, perhaps ffado-2.0.1.
So, it seems to be that problem is in either jack compilation/linkage or
in FFADO source.
I bet it's FFADO source, but we'll find out:
How to proceed from here? More tests I can perform?
You can test ffado-2.0rc2+svn1569-2 (the testing version) on new jackd.
Simply install libffado1 and overwrite/symlink to libffado2 in /usr/lib.
This way, both, old and new jackd versions can be tricked to pick up
either libffado1 or libffado2. (these libs are API/ABI compatible at the
moment, so this dirty hack can work.)
This makes sure jackd or linkage isn't the culprit.
Should I post above to upstream FFADO or Jackd developers (and if so,
how?)?
Let's first try the attached patch. It has nothing to do with the jackd
developers, since jackd code hasn't changed, only ffado.
I've already pinged ffado upstream on this bug report, and I'm somewhat
ffado upstream myself, so I'll take care of everything.
Cheerio
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
diff --git a/src/libieee1394/IsoHandler.cpp b/src/libieee1394/IsoHandler.cpp
index d33f9e6..b43e420 100644
--- a/src/libieee1394/IsoHandler.cpp
+++ b/src/libieee1394/IsoHandler.cpp
@@ -84,7 +84,6 @@ IsoHandler::IsoHandler(IsoHandlerManager manager, enum EHandlerType t)
, m_Client( 0 )
, m_speed( RAW1394_ISO_SPEED_400 )
, m_prebuffers( 0 )
- , m_dont_exit_iterate_loop( true )
, m_State( eHS_Stopped )
, m_NextState( eHS_Stopped )
, m_switch_on_cycle(0)
@@ -424,22 +423,8 @@ enum raw1394_iso_disposition IsoHandler::putPacket(
#endif
// iterate the client if required
-if(m_Client) {
-enum raw1394_iso_disposition retval = m_Client-putPacket(data, length, channel, tag, sy, pkt_ctr, dropped_cycles);
-if (retval == RAW1394_ISO_OK) {
-if (m_dont_exit_iterate_loop) {
-return RAW1394_ISO_OK;
-} else {
-m_dont_exit_iterate_loop = true;
-debugOutput(DEBUG_LEVEL_VERBOSE,
-(%p) loop exit requested\n,
-this);
-return RAW1394_ISO_DEFER;
-}
-} else {
-return retval;
-}
-}
+if(m_Client)
+return m_Client-putPacket(data, length, channel, tag, sy, pkt_ctr, dropped_cycles);
return RAW1394_ISO_OK;
}
@@ -574,19 +559,7 @@ IsoHandler::getPacket(unsigned char *data, unsigned int *length,
this, getTypeString(), *length, m_max_packet_size);
}
#endif
-if (retval == RAW1394_ISO_OK) {
-if (m_dont_exit_iterate_loop) {
-return RAW1394_ISO_OK;
-} else {
-m_dont_exit_iterate_loop = true;
-debugOutput(DEBUG_LEVEL_VERBOSE,
-(%p) loop exit requested\n,
-this);
-
[rn...@rncbc.org: [LAD] [ANN] Qtractor 0.4.4 - The Frisky Demivierge's in the wild!]
Hi! For our qtractor guys. HTH - Forwarded message from Rui Nuno Capela rn...@rncbc.org - Date: Sat, 16 Jan 2010 20:59:23 + From: Rui Nuno Capela rn...@rncbc.org To: linux-audio-...@lists.linuxaudio.org Subject: [LAD] [ANN] Qtractor 0.4.4 - The Frisky Demivierge's in the wild! What? No automation, yet? Yes I failed the promise once again. So what? What would you expect from this self-called über-procrastinator? As sure is one to say that this is the Year of Linux Desktop (YOLD:), I'll give you the shivers and command this one will be the year of Qtractor Automation. No kiddin' ;) Meanwhile, this new dot-release brings you several niceties, a couple of them have been waaay longer and dustier on the all-mighty-overdue TODO list than automation is. Rejoice! or else... Qtractor 0.4.4 (frisky demivierge) is in the wild! Release highlights: * LV2 plug-in support (NEW) * MIDI event list view (NEW) * Expedite audio/MIDI clip import (NEW) * DSSI plug-in output control ports feedback/update (NEW) * JACK transport, MMC, SPP control options (NEW) * Self-bounce/recording (FIX) * Audio/MIDI drift correction (FIX) * Anti-glitch audio micro-fade-in/out ramp smoothing (FIX) Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball: http://downloads.sourceforge.net/qtractor/qtractor-0.4.4.tar.gz - source package (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.src.rpm - binary packages (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.i586.rpm http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.x86_64.rpm - binary packages (Ubuntu 8.04 LTS; no LV2 support): http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu804_i386.deb http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu804_amd64.deb - binary packages (Ubuntu 9.10): http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu910_i386.deb http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu910_amd64.deb - user manual (ever still outdated): http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf Weblog (upstream support): http://www.rncbc.org License: Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - For all the DSSI plugins that have output control ports, a host feedback/update process cycle is now being finally provided: all output control ports are now marshaled to their respective GUI process, rather often and when found open/visible. - MIDI clip editor (aka piano-roll) snap-to-beat behavior on edit mode is now kind of more like 'filling-in-the-blanks' (as Frank Neumann et al. wishes ;) - Fixed MIDI clip editor mistake when reverting to initial clip length, before closing and discard changes (thanks to Frank Neumann, for spotting this one). - LADISH Level 1 support has been added: SIGUSR1 signal trap just makes it a shortcut to File/Save. - Avoid parameter value flickering, due to duplicate command invocation, most evident when changing values massively on native Linux VSTi plugin editor GUIs (thanks to a detailed report on this odd behavior, from Mike of linuxDSP.co.uk). - Another TODO item bites the dust: MIDI event list editor, now accessible from the MIDI clip editor menu (View/Events) - Last used session directory is now made current on startup only when no filename is given on the command line (solving bug #2920244). - Current snap-to-beat setting (time quantization) now affects the anchor event only, while dragging, moving and/or pasting multiple events over the MIDI clip editor (aka piano-roll). - Make anti-glitch audio clip micro fade-in/outs independent from current buffer size as much as possible. - Audio/MIDI engine drift correction gets really sophisticated, with the help of (now old) ALSA MIDI tempo skew facility. - Edit/Clip/Import... menu option is now available for expedite clip insertion from audio and MIDI file requesters. - Set default session directory effective to file's location. - Audio track/clip recording process has been target to special re-factorization across the internal audio engine process cycle, in a late attempt to get self-bounce/recording effective and working consistently for all track layouts. - All session related dialogs are now set to window modality, (were set to default application modality before) allowing for continued input focus and interaction on all plugin/tool windows. - An off-by-one nasty old bug fixed in audio clip drawing, was causing instant crashes on certain zoom levels of the main track view. - Graphical MIDI clip representation regarding note/pitch range is now kept as much as possible across clip edits (cut, copy, paste, drag, move, delete, etc.) - LV2 plug-in hosting has finally
Bug#565342: newly released libffado2-based jackd fails with firewire ERR: Could not start streaming threads: -1
On Fri, Jan 15, 2010 at 03:00:57PM +0100, Jonas Smedegaard wrote: Hi Adrian, Hi! Finding the right value(s) for p (and n) could be a hard job, so playing with those might be useful. Are you suggesting to shoot in the dark for magic combinations here, and that _both_ too low and too high values lead to same error messages? Absolutely. Larger unfortunately isn't better here. You are right that larger period sizes normally give the driver more time to complete its work. With firewire, it's crucial to provide a stable ISO streaming to the device, and when you increase the buffer size, packets are sent less frequently. Together with jittered timing, the device might had run out of packets, thus giving the typical xrun. This behaviour will go away when FFADO moves to kernel space and can rely on interrupts from the firewire host controller. This guarantees to be woken up by hardware as soon as possible, but since FFADO is userspace at the moment, having too large buffers could mean too long to wait to get send and receive streams correctly aligned. (this is the dry running state, a warm up phase taking place before actual operation to tune both ends (the host and the device) to their specific timings) On Juju, I usually operate my device at -p 512 and -n3 (which is the default). When I omit -p (in other words: use the default 1024), I see xruns and less stable operation. However, unless -p is extremely small, every value should at least be able to put the device into running state. If not, this might be caused by underlaying timestamp errors, which are mostly due to broken controllers. You could increase -v to let's say -v5 to get more details. If need be, file a ticket at subversion.ffado.org HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#563588: FTBFS - vamp-sdk/hostext/PluginLoader.h: No such file or directory
On Sun, Jan 03, 2010 at 03:23:09PM -0700, dann frazier wrote: Source: ardour Version: 1:2.8.4-2 Severity: serious The recent binNMU of ardour fails to build. libs/ardour/audioanalyser.cc:2:43: error: vamp-sdk/hostext/PluginLoader.h: No such file or directory This is caused by an update of vamp-plugin-sdk from 1.3 to 2.1 last week. The header files have been moved, and we'd been patching the ardour source to match the 1.3 location. I'll remove the corresponding patch (110_vamp.patch) from ardour and specify a version dependency for vamp-plugin-sdk (= 2.1). That'll fix the bug. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] fluidsynth packaging branch, master, updated. debian/1.1.1-1-2-gcb9200e
On Tue, Jan 05, 2010 at 07:55:41AM +, quadrispro-gu...@users.alioth.debian.org wrote: Author: Alessio Treglia quadris...@ubuntu.com Date: Tue Jan 5 08:55:30 2010 +0100 Add myself as uploader. How about DM-Upload-Allowed: yes in the control file? So you don't need a sponsor every time you want to upload a new package version? (you are a DM, right?) HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] fluidsynth packaging branch, master, updated. debian/1.1.1-1-2-gcb9200e
On Tue, Jan 05, 2010 at 08:58:19AM +0100, Adrian Knoth wrote: Author: Alessio Treglia quadris...@ubuntu.com Date: Tue Jan 5 08:55:30 2010 +0100 Add myself as uploader. How about DM-Upload-Allowed: yes in the control file? So you don't Race condition. I just saw your commit... -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver Heut' ass er seine letzte Semmel, tagtaeglich rauchte er nur Camel. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
reassign 561681 to ardour
# Automatically generated email from bts, devscripts version 2.10.35lenny7 reassign 561681 ardour ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: RFS: jackd
On Fri, Dec 11, 2009 at 01:33:18PM +0100, Free Ekanayaka wrote: Hi Adrian, Hi! Thanks for having changed this! I'm not too convinced by the idea of not including the 32bit library, I guess it would be handy for some users and it wouldn't hurt the others. I must confess I'm not up-to-date about the current way of multiarch in Debian. AFAIK, the chroot thing is only the last resort. Then, there was a time with fat (multiarch) binaries (the Apple way), but this seems to be abandoned. Or not, I don't know. Then, there is some magic with ia32-apt-get which installs i386 packages side-by-side on amd64 systems. That's the approach I had in mind, and this would work: an amd64 user in need for 32bit jack clients would have two libjack0 packages, one amd64 and one i386 version. I don't think there's consensus in Debian to automatically ship 32bit libs in 64bit-packages, but if somebody has better knowledge, I'm happy to add the four lines it'll take to support it. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: January meeting poll
On Thu, Dec 10, 2009 at 02:08:52PM +0100, Fabian Greffrath wrote: Hi! agenda. My problem is that I am at university all day and IRC connections are firewalled here. Have you tried some IRC webchats? There are quite a few. If not, I could still offer you an ssh account on one of my machines, so you can login and run irssi there or use ssh tunnelling. Of course, you could also run the IRC session on your computer at home and ssh into it. Just my €0.02 -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#560052: The real fix
On Thu, Dec 10, 2009 at 04:10:18PM +0100, Fabian Greffrath wrote: So we need a newer VAMP SDK in Debian. After that, this intermediate patch can be removed: http://git.debian.org/?p=pkg-multimedia/ardour.git;a=commitdiff;h=347e34548cd877123865ddd65339398123f6b6a0 But AFAIUI after removal of this patch we would still include the headers shipped in the ardour source tree but link against the Debian system library. You're right. This somewhat just hides the bug as long as ardour's VAMP source matches the system's VAMP source. Wouldn't it make more sense to always use the Debian package's headers then? ACK, I was saying too much. It seems reasonable to keep this patch. BTW, shouldn't the variable, that gets commented out by the patch, be called CPPPATH instead of CPPATH (i.e. three P instead of only 2)? http://www.scons.org/doc/0.92/HTML/scons-user/x537.html Probably yes. I've told upstream about it. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#560052: ardour-i686: Ardour with debian-patches crashes while performing audio-analysis
On Tue, Dec 08, 2009 at 04:59:40PM +0100, Klaumi Klingsporn wrote:
Hi!
Vamp::HostExt::PluginLoader: Unable to load library
/usr/lib/ardour2/vamp/libardourvampplugins.so:
/usr/lib/ardour2/vamp/libardourvampplugins.so: undefined symbol:
_ZTIN11_VampPlugin4Vamp17PluginAdapterBaseE
I can reproduce the bug, and it looks like others are facing the same
problem:
http://www.mail-archive.com/64studio-de...@lists.64studio.com/msg00400.html
To me, it looks like this:
a...@hex:~$ objdump -T /usr/lib/ardour2/vamp/libardourvampplugins.so | \
grep PluginAdapterBaseE
D *UND* _ZTIN11_VampPlugin4Vamp17PluginAdapterBaseE
So this symbol really is undefined. The lib is linked correctly:
a...@hex:~$ ldd /usr/lib/ardour2/vamp/libardourvampplugins.so | grep vamp
libvamp-sdk.so.1 = /usr/lib/libvamp-sdk.so.1 (0xb7eea000)
libvamp-hostsdk.so.2 = /usr/lib/libvamp-hostsdk.so.2 (0xb7ec3000)
I see a similar symbol in libvamp-sdk:
a...@hex:~$ objdump -T /usr/lib/libvamp-sdk.so.1 | grep AdapterBaseE
000147e4 w DO .data.rel.ro 0008 Base _ZTIN4Vamp17PluginAdapterBaseE
I've now managed to build a non-crashing version. Can you try the
attached patch? It basically boils down to removing a single line in
libs/vamp-plugins/SConscript, so you could also patch this manually.
With this patch, I'm also getting beautiful FFT graphs. ;)
If this patch does the trick, I'll upload a fixed package.
diff --git a/debian/patches/111_vamp.patch b/debian/patches/111_vamp.patch
new file mode 100644
index 000..1cb25cb
--- /dev/null
+++ b/debian/patches/111_vamp.patch
@@ -0,0 +1,12 @@
+diff --git a/libs/vamp-plugins/SConscript b/libs/vamp-plugins/SConscript
+index fd86c09..055c46d 100644
+--- a/libs/vamp-plugins/SConscript
b/libs/vamp-plugins/SConscript
+@@ -19,7 +19,6 @@ Onset.cpp
+ Import('env install_prefix libraries')
+ vampplugs = env.Clone()
+
+-vampplugs.Append (CPPATH='#libs/vamp-sdk/vamp', CXXFLAGS=-Ilibs/vamp-sdk)
+ vampplugs.Merge ([libraries['vamp'],
+ libraries['vamphost']
+ ])
diff --git a/debian/patches/series b/debian/patches/series
index e4b6bb4..7ba21cb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@
90_ardour-x-change.patch
100_syslibs.patch
110_vamp.patch
+111_vamp.patch
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
