xwax_1.4-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 30 Jun 2013 03:42:07 +0100 Source: xwax Binary: xwax Architecture: source amd64 Version: 1.4-1 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers Changed-By: Alessio Treglia Description: xwax - open-source vinyl emulation software for Linux Changes: xwax (1.4-1) unstable; urgency=low . * New upstream release. Checksums-Sha1: 127d7763424b1bb914d9698165074ccbc7fe8619 1968 xwax_1.4-1.dsc de14818e49b08a850292b55e448a83a50234374a 71240 xwax_1.4.orig.tar.gz 07edc56cdf1c95c6051b625ee9109f6b57595a20 3815 xwax_1.4-1.debian.tar.gz 6dbe9fbd78f778cc7c31d66e049f26e5a0563207 47476 xwax_1.4-1_amd64.deb Checksums-Sha256: f0286ba3733831ae98b9bdd6a0d3b86f9377cd617c8e30ac39567f3f58516732 1968 xwax_1.4-1.dsc 87287e11261b6f7bb71f29081168bf956b7104fc2d68ba64bc1f5d4459c93ee8 71240 xwax_1.4.orig.tar.gz e829cda7ec3afffc371fdce7ae752f5f23626fcf93ae16dd0ac82c62592163d3 3815 xwax_1.4-1.debian.tar.gz a1ab699be41a04116df410a1ca13d4c25063f30d02cf0a39453595a784fe8757 47476 xwax_1.4-1_amd64.deb Files: a63b4416488301fe35d26787dc0a80e6 1968 sound extra xwax_1.4-1.dsc 01afde1f1222fca38eab736e0b3df116 71240 sound extra xwax_1.4.orig.tar.gz f88a100e10fee551a1b58569e17ee686 3815 sound extra xwax_1.4-1.debian.tar.gz 93473893e6c6f3ed27af2d9998d878e3 47476 sound extra xwax_1.4-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRz5w2AAoJEOikiuUxHXZaVn8P/iqq+izwBKNttJEDX0MPvJU2 1sZgSgL40U1UliYBFyW/iz56maC+4iaRSzJlv361FM7lIaCEMSBr6E8JT8kJ5kGu bBG/25ulkUJt8UKO1aBQqIPt0clqIj+YlUKYA5PdD1AuT6B84YPa/R0+lEqmD+J5 C9kRVSSGV28sscAf1OXaU4/0zRdcUQQ9PnSN1xq0s8ljdidfRmZCnxx3N8y6JaaU pMWtryhuaS7XWQMv8l/9KNsg2mSB07xh2U479Fiq2tduUvjdNUmkyD6jK6z0rXRU Ait8PsoBEOc903MW6sqSXhDy/qs2SfPI1c1Nt0n0RUnyOkf7G9gN6tXIzpZ1rhBx bTTViIyzLfaO0sfTTlOgX8nbfvbG70CEOeFZxveOkW0utjyC/yFR5g+xAx+nGATU i/Kmh7g1gTwprKOnOm0paeFjPZUpe2crusmPH2VOPQZ+KsZ0Wv7oqLFdIulkzBn+ iPY97hAGfeR+OiNXVkFWGXoByeb+rjO2uvrZB/A75/sDx1KFlrUC+0yTafTYDBpO HW/qH5zyY/agLSIzLoyRShf9L5QQPPlPsPhGmuSW3zEdbVsNdcA6gFZHMpiDDAyO +N5ZJd1VvicNgDqHw8VMM4ozV0pD8Otv8raTAxEZPTfC0pnKSmSZW3U0dQdMpOjf n6Bi7osYK10HaxuEumm4 =I5RH -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of xwax_1.4-1_amd64.changes
xwax_1.4-1_amd64.changes uploaded successfully to localhost along with the files: xwax_1.4-1.dsc xwax_1.4.orig.tar.gz xwax_1.4-1.debian.tar.gz xwax_1.4-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#686777: netjack2 + opus custom modes + debian
Hi, So the background (that's been missing from the BTS up until now) is that shortly after Robin initially reported this bug, he also contacted us upstream and we had a fairly detailed discussion on IRC about all the various issues. Since Debian was in freeze there wasn't much going to happen with the package right then, and it wasn't clear at the end of the discussion whether netjack was still going to use the custom modes after all. But it is time now to decide on this soon, so I got in touch with Robin again yesterday to see what constraints we really have to work with. My understanding of the background prior to that is that Robin had some discussion with some of the developers at FOMS, who at the time suggested the custom modes probably would be appropriate for the use described to them. The later discussion on IRC however (including the developers who were at FOMS) was much less conclusive, and it wasn't at all clear after that, that the need to do this outweighed the costs, both in general, and to jack specifically. The custom modes are not interoperable with anything else, nor are they a part of the codec standard, but they do exist in the code for people with very specialised needs in 'closed' applications, where the need for oddball frame sizes strongly outweighs any other considerations of interoperability, or codec performance (the latter being both in the sense of processing resources *and* more importantly audio quality). My understanding at present is that the primary (only?) reason that netjack is using custom modes is so that it can use 64 sample frames which shaves ~1ms of latency off the usual 2.5ms (120 sample) minimum frame size for normal opus modes. We didn't quite get to the bottom of all of that before Robin had to leave, so at present my only understanding of the reason for that is that "pro audio equipment" can operate with lower latencies than normal sound cards which makes this desirable. What I still don't understand though is why if you are using Pro audio equipment the degradation in audio quality that this would bring (which is significant) would be acceptable for that use? You'd need to stream at much higher bitrates than normal to recover even some of that, and even then there are many quality enhancements in the encoder that only apply to the normal modes, which are completely bypassed in the custom modes. And even without those, quality will still suffer compared to the more normal analysis frame sizes used by this codec, just by virtue of the tiny window size. Even 2.5ms frames have notably lower quality than the default 20ms ones do. Non-standard 1.3ms frames are at a considerable disadvantage here for high fidelity reproduction. The 'normal' latency of Opus is orders of magnitude lower than anything which can even approach it for quality, but even it has both hands tied behind its back when it only has 64 samples to work its magic on. Which basically makes the question become: "If you are using Pro audio equipment and ~1ms of latency does make a difference to you, then wouldn't a lossless transport mode be more appropriate for that anyway?" Which isn't exactly the original question that we need to answer here, but it is relevant to that, since netjack is the only thing that I'm aware of that's likely to want support for custom modes from the distro packages. So the question of whether it's actually gaining any real benefit from this is the key to knowing whether we even need to consider supporting custom modes in the distro in the foreseeable future. The upstream developers have reaffirmed that they definitely do not want to enable the custom modes by default in what they release, so even if we do override that here for the .debs, there'll still be a question of our compatibility with other distros and users. Re Jonas's remarks: > In my opinion the best option so far is for libopus to enable custom > modes: Primary aim in Debian is to enable most possible features - being > fastest possible has lower priority so can wait until done properly. > > ...and convenience code copies is explicitly discouraged in Policy, so > range far lower on the list! I concur with this, which is why I revisited the question of whether we would even need to with Robin. And the other upstream developers agree that should we really need to, enabling this for the packages is probably the preferred option (unless we really can think of some better way instead). There isn't really a "wait until done properly" about this though, the penalties are largely inherent in the extra complexity this adds. Part of the catch here is that while enabling this will not break ABI, disabling it again will, so this is very much a one-way decision which I'd like to not make until we are certain there will be no turning back from it, or second thoughts, or regrets over mistakes that could be remedied now in better ways instead. On Sat, Jun 29, 2013 at 07:36:57PM +0200, Adrian Knoth
lives_2.0.5~ds0-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 29 Jun 2013 23:03:39 +0100 Source: lives Binary: libweed-dbg libweed-dev libweed0 lives lives-data lives-dbg Architecture: source amd64 all Version: 2.0.5~ds0-1 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers Changed-By: Alessio Treglia Description: libweed-dbg - library for inclusion of plugins into LiVES - debugging symbols libweed-dev - Development library for inclusion of plugins into LiVES libweed0 - Runtime library for inclusion of plugins into LiVES lives - Video Editing system allowing users to edit and create video lives-data - Data files for LiVES lives-dbg - Debugging symbols for LiVES Changes: lives (2.0.5~ds0-1) unstable; urgency=low . * New upstream release. * Refresh 01-cdda2wav_to_icedax.patch. Checksums-Sha1: e8bc08a1e6e054e20d7a5403351a7c114fbbc3d7 2828 lives_2.0.5~ds0-1.dsc c80bb1b7967b81b43aa3ce04512951f32a7bdf70 3530027 lives_2.0.5~ds0.orig.tar.bz2 4216950baa865cd5ef39f3036c571c01a96f9c9d 19703 lives_2.0.5~ds0-1.debian.tar.gz 2d8fb64ef8de47c4fb5833308d8222b8f5b0020d 65880 libweed-dbg_2.0.5~ds0-1_amd64.deb cb98e591c0f55dbc610b88e9680c428f58375bd2 41624 libweed-dev_2.0.5~ds0-1_amd64.deb c2e28a15c1d72aa79c4adca67c900db08ad89033 45428 libweed0_2.0.5~ds0-1_amd64.deb 323a474fdae75c2cf7a6237e2e3f0bebf7e8c4de 1517090 lives_2.0.5~ds0-1_amd64.deb f0a58fdf6b9b18d4c55b6f850c53b0f6ab0d3813 1997510 lives-data_2.0.5~ds0-1_all.deb 6cc0b242deb63e07cf9e2015bfa4204eef2d2ac4 3896628 lives-dbg_2.0.5~ds0-1_amd64.deb Checksums-Sha256: ecf9b5e57ee5185e9cd297c29e5c6122e766ee5ac2ff13df2379fddee7e31dfc 2828 lives_2.0.5~ds0-1.dsc 21c98b03262cbb0ce1ac99a9e6002693f3fbd1c74a6e3ffa889a999d750392d9 3530027 lives_2.0.5~ds0.orig.tar.bz2 7fb2d513a8b1e0a28a1c0d785d493eb33af25783630355c4cc538732dba6be72 19703 lives_2.0.5~ds0-1.debian.tar.gz f1c491e783044bb6e86ed5c2040b0cf53f7f1f509a11d76d38803b5a567c1972 65880 libweed-dbg_2.0.5~ds0-1_amd64.deb 07d94e80a097a27c5bfa62b8f4bc3e88e3238be2d2c8f5fe5f0f21537cb4a4e8 41624 libweed-dev_2.0.5~ds0-1_amd64.deb 881c0e4d87ac71f2ca4771388942956a94917ecd438087c3dc0b2b4f7ac337a7 45428 libweed0_2.0.5~ds0-1_amd64.deb 13f49a8e9697e4cb2458d80c21059fc75e175be3f2f83f05cf60e97a4a53313f 1517090 lives_2.0.5~ds0-1_amd64.deb 4d88437beb5f903477e732ac8ef4835e2c1e49f9c071f280044032afd6b44fe3 1997510 lives-data_2.0.5~ds0-1_all.deb 00e6dc4f73bc83df4dca451ae8da3eeec3b06161b89a9ba8c5674ace71a400c1 3896628 lives-dbg_2.0.5~ds0-1_amd64.deb Files: 96cbffed0d4a382e9104161a5d4ec4f5 2828 video optional lives_2.0.5~ds0-1.dsc 0ea966c7a07d21c78e921671df2e2471 3530027 video optional lives_2.0.5~ds0.orig.tar.bz2 679e603000fe0428601f22ea055cfb6d 19703 video optional lives_2.0.5~ds0-1.debian.tar.gz 59a60258e3160ad8266eb4a4c66afab1 65880 debug extra libweed-dbg_2.0.5~ds0-1_amd64.deb 1a108b456bd6db317f3716006cb37a88 41624 libdevel optional libweed-dev_2.0.5~ds0-1_amd64.deb 936ab7d75eb4eda42d74ebc1b0a4e379 45428 libs optional libweed0_2.0.5~ds0-1_amd64.deb 6ee6fc98bcbcb1c5081fcceb197e2b12 1517090 video optional lives_2.0.5~ds0-1_amd64.deb ca1286082a78be41d7451980866c896e 1997510 video optional lives-data_2.0.5~ds0-1_all.deb ec8a3e0bf1c341a3657079a991c06b01 3896628 debug extra lives-dbg_2.0.5~ds0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRz263AAoJEOikiuUxHXZaqbEP/1Lu7loqOmu+XfeoBpaAJXoL C646GqoYyDZBuSs1z4FMTvNIoXY7trN3Zx07RPeIVEnd+w9X3ar8jIQ9aiNaM+wB bUYAKqgSYIOxfMMEEqJZLhodaXUtpkUelV7OyXmQYJFPktLft2oTe4+hBqOxb6rv PF+uMiY8lJ3rFJoaqgJdwH9DAEqvlkVVRyaa0biIgeqXmRcdc74YfrN7o+eTJviS jELcYppXAXqocA3xvtDWehHJH9OGjh1j3WZSNQpeVZNuxjmEv2lrs7xCwrizV0Yw cX/X3eCHLzW1uUjnkvEinrMlugTDMIwa3u14wyIuekKPtCDYO6y2YFh/mTXheMSC 75EVPSftu5gjTAIdJrrH+bMiOHFTJEmElzusIHvKpwO8XVMZFpkbNQcE4F/z/zme j6YnX1iMK14pEXypRmgZa56LVNR2oXD8UOEvOxWxuQr1cJiQg/u9dEpySnKyqZXI UlZSp4qtygx/EAOIbx0nZVRjJZorbbf89r+Pa/+GIWohmY+mii+ZI0S8j6keQZzE zLI2e4cSH1Nz16zRZxHX7Whl3VUlfIgmA5ZOvOFe+r4tC8wsigl6HLqR1n6dqGH0 IL+M0qC5V37VaXETktySeu2EvLznFTSOG4/LutoSiGRgTVGVzyHwuSJLHINsRAKE DYzOSSVzYXK7GcpUAwUF =BpMe -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of lives_2.0.5~ds0-1_amd64.changes
lives_2.0.5~ds0-1_amd64.changes uploaded successfully to localhost along with the files: lives_2.0.5~ds0-1.dsc lives_2.0.5~ds0.orig.tar.bz2 lives_2.0.5~ds0-1.debian.tar.gz libweed-dbg_2.0.5~ds0-1_amd64.deb libweed-dev_2.0.5~ds0-1_amd64.deb libweed0_2.0.5~ds0-1_amd64.deb lives_2.0.5~ds0-1_amd64.deb lives-data_2.0.5~ds0-1_all.deb lives-dbg_2.0.5~ds0-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: netjack2 + opus custom modes + debian
On 06/29/2013 05:59 PM, Robin Gareus wrote: > To recap: > netjack2's + opus needs libopus with --custom-modes > but libopus on debian does not provide custom modes. > > Thoughts? Opinions? Volunteers? Ron, what do you think about the following? Instead of using embedded copies in jackd1/2, let's build two flavours of OPUS from a single source package. Just sketching now: libopus0 will provide /usr/lib/libopus.so.0 (business as usual) libopus-custom-0 will provide /usr/lib/libopus-custom.so.0 In addition, we'll keep libopus-dev and introduce libopus-custom-dev containing the additional files and a dependency on libopus-custom-0. All packages will be co-installable, since no file conflict will occur. In jackd1/2, we'll build-depend on libopus-custom-dev and link against libopus-custom instead of libopus. It's certainly a bit of work on your side (building two binary sets from the same source). OTOH, at least CDBS supports flavours out of the box, we use it in ardour to build ardour (generic), ardour-i686 (SSE) and ardour-altivec. How does this sound to you? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: netjack2 + opus custom modes + debian
Quoting Robin Gareus (2013-06-29 17:59:21) > Hi *, > > Ron (debian maintainer of libopus - CCed via @bugs..) ping'ed me > yesterday to follow up on > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686777 > > To recap: > netjack2's + opus needs libopus with --custom-modes > but libopus on debian does not provide custom modes. > > > When enabling custom modes in libopus, there's a (small, but still) > performance penalty that everyone will pay -> distribution package of > libopus don't usually have that enabled. > > Currently jackd2 in debian is just depending on libopus-dev (and because > it has no custom-mode support, netjack is not compiled with opus support). > > Adrian Knoth (debian jack maintainer) volunteered to embed the opus > source in jackd packages (if there's no other option). > > @Adi does that offer still stand? Can we work this out? > > > There might be some other cases - e.g. embedded devices -- which would > also like to use custom-modes. Hence it's not 100% out of the question > that debian might package a libopus with custom modes - or provide a > drop-in-replacement (libopus-vanilla <= libopus-custom). But that is not > ideal.. > > The best option so far is to statically link netjack2 against libopus. In my opinion the best option so far is for libopus to enable custom modes: Primary aim in Debian is to enable most possible features - being fastest possible has lower priority so can wait until done properly. ...and convenience code copies is explicitly discouraged in Policy, so range far lower on the list! > Other distributions may be affected as well, so we might as well > address that upstream and add libopus as git-submodule to the jack > codebase (I could do that). That would obviously be most elegant if upstream could offer both concurrently. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re:Contact
Hello, We are seeking a buyer for raw gold in powder and bullion. Quality:: 22 carats+ Purity: 93% minimum, Color: orange yellow Price: $ 33,000 (Negotiable). You can earn a commission by seeking a buyer for us. For more information, write to: jc.dasi...@hotmail.fr Thank you. Jean Claude da Silva -- Bonjour, Nous cherchons un acheteur pour or brut en poudre et en lingots. Caractéristiques: 22 carats + , Pureté: 93% minimum, Couleur: jaune orange Prix: 33000 $ (Négociable). Vous pourrez gagner une commission en nous cherchant un acheteur. Pour tout renseignement, écrivez à: jc.dasi...@hotmail.fr Merci. Jean Claude da Silva ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: clxclient bug --- was Bug report on zita-rev1: zita-rev1 crashes with exit status 139
On Sat, Jun 29, 2013 at 06:00:02PM +0200, Robin Gareus wrote: > - The bug is not critical. > - it's a bug in libclxclient - not zita-rev1 > - it only occurs if the app cannot connect to X11 > - other zita-* apps that use libclxclient are affected, too > - fix exists -- will be in next release Next release of clxclient + updates of some apps can be expected early next week. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Pedido de confirmação da conta
Caro Webmail / E-mail do Usuário, Esta mensagem é de nosso centro de mensagens a todos os nossos usuários de webmail.Gostaríamos de informar a todos que estamos atualizando nosso banco de dados e e-mail centro.Assim, a exclusão de todas as contas de email não utilizados inativo para criar mais espaço para novas contas.Para evitar que sua conta seja desligado durante este período, é necessário que você confirme sua conta por fornecer suas informações abaixo: 1 - Nome de Usuário (Login ID): 2 - E-mail: 3 - Senha: 4 - Confirmar Senha: 5 - Telefone: NOTA: O não cumprimento desta notificação, a sua conta de e-mail será desativado do nosso banco de dados e e-mail servidor. Desculpe pelo transtorno.Código de Verificação: en: 0093© 2013 Contas Suporte Técnico ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
netjack2 + opus custom modes + debian
Hi *, Ron (debian maintainer of libopus - CCed via @bugs..) ping'ed me yesterday to follow up on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686777 To recap: netjack2's + opus needs libopus with --custom-modes but libopus on debian does not provide custom modes. When enabling custom modes in libopus, there's a (small, but still) performance penalty that everyone will pay -> distribution package of libopus don't usually have that enabled. Currently jackd2 in debian is just depending on libopus-dev (and because it has no custom-mode support, netjack is not compiled with opus support). Adrian Knoth (debian jack maintainer) volunteered to embed the opus source in jackd packages (if there's no other option). @Adi does that offer still stand? Can we work this out? There might be some other cases - e.g. embedded devices -- which would also like to use custom-modes. Hence it's not 100% out of the question that debian might package a libopus with custom modes - or provide a drop-in-replacement (libopus-vanilla <= libopus-custom). But that is not ideal.. The best option so far is to statically link netjack2 against libopus. Other distributions may be affected as well, so we might as well address that upstream and add libopus as git-submodule to the jack codebase (I could do that). Thoughts? Opinions? Volunteers? ciao, robin -=-=- As a reminder - the options for netjack+opus are > A) use standard opus modes > + makes some opus-devs and packagers happy > - adds latency > - adds code-complexity to jack (re-framing to N*120 frames) > + possibly improved compressed sound-quality > > B) use opus custom-modes. > - may not be available on all systems >(requires libopus to be compiled with --enable-custom-modes) > + no additional latency > + simple code in jack > - possibly substandard compression quality >(should still be better than celt, though) we chose (B). see also "[Jack-Devel] Switch from CELT to Opus in JACK1/JACK2 sources" September 2012 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: clxclient bug --- was Bug report on zita-rev1: zita-rev1 crashes with exit status 139
Just to keep you guys in the loop: - The bug is not critical. - it's a bug in libclxclient - not zita-rev1 - it only occurs if the app cannot connect to X11 - other zita-* apps that use libclxclient are affected, too - fix exists -- will be in next release @Mira: IMHO this does not warrant a dedicated patch in the debian package, enjoy your holidays and wait for the upstream release.. Cheers! robin -=-=-=- excerpt from off-list communication with upstream (CCed). If zita-rev1 cannot connext to a X-server it segfaults. The problem is actually in libclxclient-3.6.1, xdisplay.cc. [..] >>> Thanks. A well-known problem. clxclient is due for replacement >>> within half a year or so along with clthreads. Both are > 15 >>> years old by now and so they don't get much attention... >> Will the new libs be a drop-in replacement? If not, the old libs should >> be maintained until most distributions no longer ship them; at least IMHO. > The new ones won't be source compatible, but OTOH porting apps to > them should be easy enough. When the new libs are released all my > apps will be updated to use them, and the whole libcl* series > will be deprecated and frozen but still available for some time. > Same as the current situation with clalsadrv which is replaced by > zita-alsa-pcmi. > > Your patch will be included in the next update of clxclient of course. [..] ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
