Greetings
My name is Ms Anita Yousuf from London, I have an Important discussion I will like to have with you. Its private and nbsp;nbsp;nbsp; Urgent please kindly Contact me on my email at nbsp;nbsp;nbsp; anitayou...@gmail.com ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Please move Audacious from Debian experimental to Debian unstable
Hi Jürgen, I am one of those who maintain the Audacious package. I am working on getting Audacious 2.4.4 into Debian Unstable. Right now the situation is like this: Unstable: Audacious 2.3 Experimental: Audacious 2.4.3 Within 1 week, I'll get Audacious 2.4.4 into Debian Unstable hence making the package in sync between both unstable and experimental. Cheers, Bilal Akhtar On 03/24/2011 07:41 AM, Jürgen Göricke wrote: Hello Debian Audacious Packagers! Is it possible the package audacious version 2.4.3 from Debian experimental move to Debian Unstable? The package audacious with version 2.3 know, a tumble while doing instabilities online streams with long maturity. The version of the package audacious from Debian experimental, playing without problems the online radio streams. The codec used is MPEG 2/4 ACC. I hope you understand my question, because my English is not very good. My nativ language is german. The system used is Debian testing i386 (minimal installation) with lxde-core or xfce4. send Requests on my email address please Best regards Jürgen Göricke ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers -- Bilal Akhtar - Ubuntu Developer bilalakh...@ubuntu.com IRC nick: cdbs signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
serd_0~svn128-1_amd64.changes is NEW
(new) libserd-dev_0~svn128-1_all.deb optional libdevel lightweight RDF syntax library - development files Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle and NTriples. . This package provides the development files for Serd. (new) libserd0_0~svn128-1_amd64.deb optional libs lightweight RDF syntax library Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle and NTriples. . Serd is not intended to be a swiss-army knife of RDF syntax, but rather is suited to resource limited applications, or situations where a simple reader/writer with minimal dependencies is ideal (e.g. in LV2 hosts or plugins). . Serd is: * small: Serd is implemented in under 2500 lines1 of standard C code. * portable and dependency-free: Serd uses only the C standard library, and has no external dependencies, making it a lightweight dependency in every sense. * fast and lightweight: Serd (and the included serdi tool) can be used to stream abbreviated Turtle (unlike many other tools which can not stream since they must first build an internal model to abbreviate). In other words, Serd can re-serialise an unbounded amount of Turtle using a fixed amount of memory, preserving the abbreviations in the input. * conformant and well-tested: Serd is written to the Turtle, NTriples and URI specifications, and includes a comprehensive test suite which includes all the normative examples from the Turtle specification, all the normal examples from the URI specification, and additional tests added specifically for Serd. The test suite has over 96% code coverage (by line), and runs with zero memory errors or leaks. (new) serd-dbg_0~svn128-1_amd64.deb extra debug lightweight RDF syntax library - debugging symbols Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle and NTriples. . This package contains the debugging symbols for serd. (new) serd_0~svn128-1.debian.tar.gz optional libs (new) serd_0~svn128-1.dsc optional libs (new) serd_0~svn128.orig.tar.bz2 optional libs (new) serdi_0~svn128-1_amd64.deb optional text lightweight RDF syntax library - serdi tool Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle and NTriples. . This package provides the utility 'serdi'. Changes: serd (0~svn128-1) unstable; urgency=low . * Initial release. (Closes: #619429) Override entries for your package: Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 619429 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: New upstream release: 0.7.1
Hi, I'm working on the lash-ladish transition task, and ladish provides a GUI called gladish which needs flowcanvas = 0.6.4 to build. Hence, I intend to NMU this within few hours and upload the new upstream release to DELAYED/10 for Debian experimental. Regards, -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Question: depending on multiple sound server libraries
Hello list! I have a question about dependency of packages on multiple sound server libraries. The cmus [1] audio player has multiple output plugins, like roar, alsa, pulse, ao, etc. The package used to depend on all those libraries, but then users complained [2] because libroar1 recommends the roaraudio server. Although this is fixed now (libroar1 only suggests roaraudio), I wonder what would be the best solution for this problem: a) make cmus-plugin-* packages for all plugins which require additional dependencies (like in sox) b) only make cmus-plugin-* packages for rarely used plugins (e.g. roar) and depend on e.g. libpulse0 c) depend on (almost) all dependencies I know normally a) would be the way to go, but since the player is really small I don't know if it's worth to split it into 7+ packages... What do you think? The maintainer asked me to forward my question to the list. Thanks for your help! [1] http://packages.debian.org/sid/cmus [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612887 Johannes pgpMYKSQE3MZa.pgp Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Question: depending on multiple sound server libraries
On Thu, Mar 24, 2011 at 11:41:09 (CET), Johannes Weißl wrote: Hello list! I have a question about dependency of packages on multiple sound server libraries. The cmus [1] audio player has multiple output plugins, like roar, alsa, pulse, ao, etc. The package used to depend on all those libraries, but then users complained [2] because libroar1 recommends the roaraudio server. Although this is fixed now (libroar1 only suggests roaraudio), I wonder what would be the best solution for this problem: a) make cmus-plugin-* packages for all plugins which require additional dependencies (like in sox) b) only make cmus-plugin-* packages for rarely used plugins (e.g. roar) and depend on e.g. libpulse0 c) depend on (almost) all dependencies I know normally a) would be the way to go, but since the player is really small I don't know if it's worth to split it into 7+ packages... What do you think? If cmus handles missing libraries gracefully, you could do what xine did in the past, namely putting the dependencies in the 'Recommends' or even 'Suggests' field instead of 'Depends'. Xine abandoned that idea in the end, however. While from the maintenance side, it was quite maintainable (at least IMO), it wasn't really that well accepted by the users AFAIR, so xine now does it similar to vlc and packs its modules in a rather artificially selected set of packages which turned out to become very hard to get right. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] ecasound/master: update *.symbols files for the libraries
On Thu, Mar 24, 2011 at 06:56:02AM +0100, Reinhard Tartler wrote:
On Wed, Mar 23, 2011 at 22:59:22 (CET), Alessandro Ghedini wrote:
On Wed, Mar 23, 2011 at 10:24:22PM +0100, Reinhard Tartler wrote:
On Wed, Mar 23, 2011 at 21:55:14 (CET),
ghedo-gu...@users.alioth.debian.org wrote:
The following commit has been merged in the master branch:
commit c13b7176fe7823bead9078961696295f94ff26e7
Author: Alessandro Ghedini al3x...@gmail.com
Date: Wed Mar 23 20:55:45 2011 +0100
update *.symbols files for the libraries
diff --git a/debian/libecasound22.symbols b/debian/libecasound22.symbols
index d7af24a..5605429 100644
--- a/debian/libecasound22.symbols
+++ b/debian/libecasound22.symbols
@@ -65,6 +65,7 @@ libecasound.so.22 libecasound22 #MINVER#
_ZN10ECA_LOGGER8lock_repE@Base 2.7.2
_ZN10ECA_OBJECTD0Ev@Base 2.7.2
_ZN10ECA_OBJECTD1Ev@Base 2.7.2
+ _ZN10ECA_OBJECTD2Ev@Base 2.7.2
Can you actually read this mangled mess of symbols?
I still think .symbols file are largely practically useless for C++
libraries...
AFAIK they are not meant to be read by humans, but they can be used by dpkg
for generating more accurate library dependencies.
They are supposed to be actively maintained by the package maintainer,
so no, AFAIUI they are supposed to be read by humans.
What the maintainer is supposed to do with those files is checking for
backwards-compatibility brekage and, if the case, bump the version for
those broken symbols. Nothing that can't be done in few seconds using
tools such as grep (until dpkg-gensymbols will support this).
Since thay are automatically generated, there's no much work needed to
maintain these files.
Anyway, they can be demangled using c++filt(1), if needed.
And I'd say this is badly needed in this case at hand.
I don't get this, what's wrong with doing:
$ c++filt debian/package.symbols | less
Also, there is the no-symbols-control-file lintian tag. It's just whishlist
severity, but IMHO it's nice to keep lintian as silent as possible :)
We had this argument before. We are not linitan pleasers, we want to
please our users by creating technically correct and maintainable
packages. Not every lintian warning makes sense, please take them with a
grain of salt.
Isn't creating technically correct and maintainable packages the whole
point of why the *.symbols files exist? They help in creating more accurate
dependencies between packages, and, I may be wrong, but, to me, they don't
seem that scary or non-sense to need a removal.
If you insist I will of course remove them (we are a team, and we are
supposed to work togeter) but I fail at seeing the reason behind this.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Question: depending on multiple sound server libraries
On Thu, Mar 24, 2011 at 11:41:09AM +0100, Johannes Weißl wrote: I have a question about dependency of packages on multiple sound server libraries. The cmus [1] audio player has multiple output plugins, like roar, alsa, pulse, ao, etc. The package used to depend on all those libraries, but then users complained [2] because libroar1 recommends the roaraudio server. Although this is fixed now (libroar1 only suggests roaraudio), I wonder what would be the best solution for this problem: a) make cmus-plugin-* packages for all plugins which require additional dependencies (like in sox) b) only make cmus-plugin-* packages for rarely used plugins (e.g. roar) and depend on e.g. libpulse0 c) depend on (almost) all dependencies I know normally a) would be the way to go, but since the player is really small I don't know if it's worth to split it into 7+ packages... What do you think? The maintainer asked me to forward my question to the list. Thanks for your help! I disagree that there is a single normal approach. All of above are normal. And I agree that size of the package is relevant too when judging. Debian generally aims at enabling most possible features. That is good initially, to challenge maturity of features and to ensure least possible features conflict with each other when enabled concurrently. When possible and sensible, it makes sense to add choice of avoiding some of those features. One approach is flavored packages (i.e. faster (optimized for certain hardware) or lightweight (avoiding certain features). But even if upstream codes in a nice flexible way (e.g. using runtime loadable modules) it might not be sensible for Debian to make use of it. Example: I have maintained a non-X11 variant of a graphics library for some years, due to it being popular for web services and its support for the infrequently used graphics format Xpm caused it to pull in 70MB of X11 libraries. But now that Xorg have been better structured and packaged, the pulled-in X11 libraries are down to less than 10MB (I guess - haven't inspected closely recently) I consider dropping that flavoring both to simplify maintainance (not only for me - dependent packages are obviously affected by the flavoring too) and to reduce the number of packages in the Debian archive. So there is no simple answer. Not even a simple answer for when is a package too small for splitting up. For the concrete case, I suggest to keep it simple and package everything together. Only if it largely affects actual use it is sensible to look at splitting up packaging - or more likely: look into better ways to solve the problem, like repackaging Xorg as in my example above, or improving package relations as in the roar daemon case. Hope that helps. - 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: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: New upstream release: 0.7.1
Hi again, the gzip'd NMU-diff is attached. Regards, -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 flowcanvas_0.6.0-1.1-flowcanvas_0.7.1-0.1.diff.gz Description: GNU Zip compressed data ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Question: depending on multiple sound server libraries
Hello Reinhard, On Thu, Mar 24, 2011 at 12:30:35PM +0100, Reinhard Tartler wrote: If cmus handles missing libraries gracefully, you could do what xine did in the past, namely putting the dependencies in the 'Recommends' or even 'Suggests' field instead of 'Depends'. I forgot to mention, this is what cmus currently (since 15 Mar 2011) does. The problem is, cmus doesn't handle modules with unresolved symbols gracefully (prints error message to stderr). I think this is justified, because normally it indicates an unwanted mistake. Xine abandoned that idea in the end, however. While from the maintenance side, it was quite maintainable (at least IMO), it wasn't really that well accepted by the users AFAIR, so xine now does it similar to vlc and packs its modules in a rather artificially selected set of packages which turned out to become very hard to get right. Yes, I can imagine that it can be hard to get right. Fortunately it might be easier for cmus. I couldn't find shared modules in /usr/lib that have unresolved symbols on my systems, so I thought maybe this isn't a desirable solution at all. Johannes pgpaJligSOXMX.pgp Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of ll-scope_0.2.1-3_amd64.changes
ll-scope_0.2.1-3_amd64.changes uploaded successfully to localhost along with the files: ll-scope_0.2.1-3.dsc ll-scope_0.2.1-3.debian.tar.gz ll-scope_0.2.1-3_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/mailman/listinfo/pkg-multimedia-maintainers
Processing of vlc_1.1.8-1_amd64.changes
vlc_1.1.8-1_amd64.changes uploaded successfully to localhost along with the files: vlc_1.1.8-1.dsc vlc_1.1.8.orig.tar.bz2 vlc_1.1.8-1.debian.tar.gz libvlc-dev_1.1.8-1_amd64.deb libvlc5_1.1.8-1_amd64.deb libvlccore-dev_1.1.8-1_amd64.deb libvlccore4_1.1.8-1_amd64.deb mozilla-plugin-vlc_1.1.8-1_amd64.deb vlc_1.1.8-1_amd64.deb vlc-data_1.1.8-1_all.deb vlc-dbg_1.1.8-1_amd64.deb vlc-nox_1.1.8-1_amd64.deb vlc-plugin-fluidsynth_1.1.8-1_amd64.deb vlc-plugin-ggi_1.1.8-1_amd64.deb vlc-plugin-jack_1.1.8-1_amd64.deb vlc-plugin-notify_1.1.8-1_amd64.deb vlc-plugin-pulse_1.1.8-1_amd64.deb vlc-plugin-sdl_1.1.8-1_amd64.deb vlc-plugin-svg_1.1.8-1_amd64.deb vlc-plugin-svgalib_1.1.8-1_amd64.deb vlc-plugin-zvbi_1.1.8-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/mailman/listinfo/pkg-multimedia-maintainers
Bug#619492: ITP: tetraproc -- Tetrahedral Microphone Processor for Ambisonic Recording
Package: wnpp Severity: wishlist Owner: Alessio Treglia ales...@debian.org * Package name: tetraproc Version : 0.8.2 Upstream Author : Fons Adriaensen f...@linuxaudio.org * URL : http://kokkinizita.linuxaudio.org/linuxaudio/index.html * License : GPL Programming Lang: C++ Description : Tetrahedral Microphone Processor for Ambisonic Recording TetraProc converts the A-format signals from a tetrahedral Ambisonic microphone into B-format signals ready for recording. Main features: . * A-B conversion using a classic scalar matrix and minimum phase filters, or * A-B conversion using a 4 by 4 convolution matrix using measured or computed impulse responses, or a combination of both. * Individual microphone calibration facilities. * 24 dB/oct higpass filters. * Metering, monitoring and test facilities. * Virtual stereo mic for stereo monitoring or recording. * Unlimited number of stored configurations. * Jack client with graphical user interface. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
ll-scope_0.2.1-3_amd64.changes ACCEPTED into unstable
Accepted: ll-scope_0.2.1-3.debian.tar.gz to main/l/ll-scope/ll-scope_0.2.1-3.debian.tar.gz ll-scope_0.2.1-3.dsc to main/l/ll-scope/ll-scope_0.2.1-3.dsc ll-scope_0.2.1-3_amd64.deb to main/l/ll-scope/ll-scope_0.2.1-3_amd64.deb Override entries for your package: ll-scope_0.2.1-3.dsc - source sound ll-scope_0.2.1-3_amd64.deb - optional sound Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
tetraproc_0.8.2-1_amd64.changes is NEW
(new) tetraproc_0.8.2-1.debian.tar.gz optional sound (new) tetraproc_0.8.2-1.dsc optional sound (new) tetraproc_0.8.2-1_amd64.deb optional sound Tetrahedral Microphone Processor for Ambisonic Recording TetraProc converts the A-format signals from a tetrahedral Ambisonic microphone into B-format signals ready for recording. Main features: . * A-B conversion using a classic scalar matrix and minimum phase filters, or * A-B conversion using a 4 by 4 convolution matrix using measured or computed impulse responses, or a combination of both. * Individual microphone calibration facilities. * 24 dB/oct higpass filters. * Metering, monitoring and test facilities. * Virtual stereo mic for stereo monitoring or recording. * Unlimited number of stored configurations. * Jack client with graphical user interface. (new) tetraproc_0.8.2.orig.tar.bz2 optional sound Changes: tetraproc (0.8.2-1) unstable; urgency=low . * Initial release (Closes: #619492). Override entries for your package: Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 619492 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
vlc_1.1.8-1_amd64.changes ACCEPTED into unstable
Accepted: libvlc-dev_1.1.8-1_amd64.deb to main/v/vlc/libvlc-dev_1.1.8-1_amd64.deb libvlc5_1.1.8-1_amd64.deb to main/v/vlc/libvlc5_1.1.8-1_amd64.deb libvlccore-dev_1.1.8-1_amd64.deb to main/v/vlc/libvlccore-dev_1.1.8-1_amd64.deb libvlccore4_1.1.8-1_amd64.deb to main/v/vlc/libvlccore4_1.1.8-1_amd64.deb mozilla-plugin-vlc_1.1.8-1_amd64.deb to main/v/vlc/mozilla-plugin-vlc_1.1.8-1_amd64.deb vlc-data_1.1.8-1_all.deb to main/v/vlc/vlc-data_1.1.8-1_all.deb vlc-dbg_1.1.8-1_amd64.deb to main/v/vlc/vlc-dbg_1.1.8-1_amd64.deb vlc-nox_1.1.8-1_amd64.deb to main/v/vlc/vlc-nox_1.1.8-1_amd64.deb vlc-plugin-fluidsynth_1.1.8-1_amd64.deb to main/v/vlc/vlc-plugin-fluidsynth_1.1.8-1_amd64.deb vlc-plugin-ggi_1.1.8-1_amd64.deb to main/v/vlc/vlc-plugin-ggi_1.1.8-1_amd64.deb vlc-plugin-jack_1.1.8-1_amd64.deb to main/v/vlc/vlc-plugin-jack_1.1.8-1_amd64.deb vlc-plugin-notify_1.1.8-1_amd64.deb to main/v/vlc/vlc-plugin-notify_1.1.8-1_amd64.deb vlc-plugin-pulse_1.1.8-1_amd64.deb to main/v/vlc/vlc-plugin-pulse_1.1.8-1_amd64.deb vlc-plugin-sdl_1.1.8-1_amd64.deb to main/v/vlc/vlc-plugin-sdl_1.1.8-1_amd64.deb vlc-plugin-svg_1.1.8-1_amd64.deb to main/v/vlc/vlc-plugin-svg_1.1.8-1_amd64.deb vlc-plugin-svgalib_1.1.8-1_amd64.deb to main/v/vlc/vlc-plugin-svgalib_1.1.8-1_amd64.deb vlc-plugin-zvbi_1.1.8-1_amd64.deb to main/v/vlc/vlc-plugin-zvbi_1.1.8-1_amd64.deb vlc_1.1.8-1.debian.tar.gz to main/v/vlc/vlc_1.1.8-1.debian.tar.gz vlc_1.1.8-1.dsc to main/v/vlc/vlc_1.1.8-1.dsc vlc_1.1.8-1_amd64.deb to main/v/vlc/vlc_1.1.8-1_amd64.deb vlc_1.1.8.orig.tar.bz2 to main/v/vlc/vlc_1.1.8.orig.tar.bz2 Override entries for your package: libvlc-dev_1.1.8-1_amd64.deb - optional libdevel libvlc5_1.1.8-1_amd64.deb - optional libs libvlccore-dev_1.1.8-1_amd64.deb - optional libdevel libvlccore4_1.1.8-1_amd64.deb - optional libs mozilla-plugin-vlc_1.1.8-1_amd64.deb - optional video vlc-data_1.1.8-1_all.deb - optional video vlc-dbg_1.1.8-1_amd64.deb - extra debug vlc-nox_1.1.8-1_amd64.deb - optional video vlc-plugin-fluidsynth_1.1.8-1_amd64.deb - optional video vlc-plugin-ggi_1.1.8-1_amd64.deb - optional video vlc-plugin-jack_1.1.8-1_amd64.deb - optional video vlc-plugin-notify_1.1.8-1_amd64.deb - optional video vlc-plugin-pulse_1.1.8-1_amd64.deb - optional video vlc-plugin-sdl_1.1.8-1_amd64.deb - optional video vlc-plugin-svg_1.1.8-1_amd64.deb - optional video vlc-plugin-svgalib_1.1.8-1_amd64.deb - optional video vlc-plugin-zvbi_1.1.8-1_amd64.deb - optional video vlc_1.1.8-1.dsc - source video vlc_1.1.8-1_amd64.deb - optional video Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 607869 Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#607869: marked as done (vlc: rc.lua inteface listening on tcp doesn't close sockets if remote end closes the connection)
Your message dated Thu, 24 Mar 2011 15:50:24 +
with message-id e1q2mno-0002h2...@franck.debian.org
and subject line Bug#607869: fixed in vlc 1.1.8-1
has caused the Debian Bug report #607869,
regarding vlc: rc.lua inteface listening on tcp doesn't close sockets if remote
end closes the connection
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
607869: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607869
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: vlc
Version: 1.1.3-1
Severity: normal
Tags: upstream patch
When vlc is launched with the remote control interface listening on tcp, if a
remote client connects to the interface and later on, it closes the connection,
the accepted socket in vlc is not closed, so it remains in CLOSE_WAIT state.
Launching vlc with these options:
$ vlc -vvv -I rc --lua-config rc={host='localhost:4212'} -S sap -f
and connecting and disconnecting 4 times with netcat:
$ netcat 127.0.0.1 4212
the last four lines in the vlc output are:
[0x9d2a214] [rc] main interface debug: accepted socket 28 (from socket 25)
[0x9d2a214] [rc] main interface debug: accepted socket 29 (from socket 25)
[0x9d2a214] [rc] main interface debug: accepted socket 30 (from socket 25)
[0x9d2a214] [rc] main interface debug: accepted socket 31 (from socket 25)
and performing an lsof -i to the vlc process, we can see the 4 tcp sockets in
CLOSE_WAIT state:
vlc 20900 sgimeno 28u IPv4 2798961 0t0 TCP
palkia:4212-palkia:44033 (CLOSE_WAIT)
vlc 20900 sgimeno 29u IPv4 2799486 0t0 TCP
palkia:4212-palkia:44035 (CLOSE_WAIT)
vlc 20900 sgimeno 30u IPv4 2799724 0t0 TCP
palkia:4212-palkia:35849 (CLOSE_WAIT)
vlc 20900 sgimeno 31u IPv4 2799773 0t0 TCP
palkia:4212-palkia:35850 (CLOSE_WAIT)
I have created a simple patch that solves this issue for me:
*** ./vlc-1.1.3/share/lua/intf/rc.lua 2010-12-23 10:57:40.0 +0100
--- ./vlc-1.1.3/share/lua/intf/rc.lua.bueno 2010-12-23 10:40:15.0
+0100
***
*** 688,691
--- 688,696
client.buffer = quit
done = true
+ elseif client.buffer ==
+ and (client.type == host.client_type.net and input == ) then
+ -- Connection closed by remote end
+ client.buffer = quit
+ done = true
else
client.buffer = client.buffer .. input
Thanks.
Best regards,
Santi
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages vlc depends on:
ii libaa1 1.4p5-38 ascii art library
ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib
ii libfreetype62.4.2-2.1FreeType 2 font engine, shared lib
ii libfribidi0 0.19.2-1 Free Implementation of the Unicode
ii libgcc1 1:4.4.5-8GCC support library
ii libgl1-mesa-glx [libgl1 7.7.1-4 A free implementation of the OpenG
ii libqtcore4 4:4.6.3-4Qt 4 core module
ii libqtgui4 4:4.6.3-4Qt 4 GUI module
ii libsdl-image1.2 1.2.10-2+b2 image loading library for Simple D
ii libsdl1.2debian 1.2.14-6.1 Simple DirectMedia Layer
ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3
ii libtar 1.2.11-6 C library for manipulating tar arc
ii libvlccore4 1.1.3-1 base library for VLC and its modul
ii libx11-62:1.3.3-4X11 client-side library
ii libx11-xcb1 2:1.3.3-4Xlib/XCB interface library
ii libxcb-keysyms1 0.3.6-1 utility libraries for X C Binding
ii libxcb-randr0 1.6-1X C Binding, randr extension
ii libxcb-shm0 1.6-1X C Binding, shm extension
ii libxcb-xv0 1.6-1X C Binding, xv extension
ii libxcb1 1.6-1X C Binding
ii libxext62:1.1.2-1X11 miscellaneous extension librar
ii ttf-freefont20090104-7 Freefont Serif, Sans and Mono True
ii vlc-nox 1.1.3-1 multimedia player and streamer (wi
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages vlc recommends:
ii
Bug#619530: ffmpeg: backport of 4:0.6.1-5 from unstable produces WARNING: library configuration mismatch
Package: ffmpeg Version: 4:0.6.1-5 Severity: minor Hi, I backported ffmpeg 4:0.6.1-5 from unstable to squeeze. On running it, I see the following warning WARNING: library configuration mismatch inter alia. The complete output of ffmpeg is given below. I don't know if the version on unstable has the same problem, and I don't have an unstable installation handy right now to test with. However, if it does not, that makes me wonder why it should show up in a backport. Regards, Faheem * FFmpeg version 0.6.1-4:0.6.1-5, Copyright (c) 2000-2010 the FFmpeg developers built on Mar 24 2011 17:36:33 with gcc 4.4.5 configuration: --extra-version=4:0.6.1-5 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --disable-stripping --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-x11grab --enable-libdirac --enable-libfaad --enable-librtmp --enable-libdc1394 --enable-shared --disable-static WARNING: library configuration mismatch libavutil configuration: --extra-version=4:0.6.1-5 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --disable-stripping --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-x11grab --enable-libdirac --enable-libfaad --enable-librtmp --enable-libdc1394 --shlibdir=/usr/lib/i686/cmov --cpu=i686 --enable-shared --disable-static --disable-ffmpeg --disable-ffplay libavcodec configuration: --extra-version=4:0.6.1-5 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --disable-stripping --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-x11grab --enable-libdirac --enable-libfaad --enable-librtmp --enable-libdc1394 --shlibdir=/usr/lib/i686/cmov --cpu=i686 --enable-shared --disable-static --disable-ffmpeg --disable-ffplay libavformat configuration: --extra-version=4:0.6.1-5 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --disable-stripping --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-x11grab --enable-libdirac --enable-libfaad --enable-librtmp --enable-libdc1394 --shlibdir=/usr/lib/i686/cmov --cpu=i686 --enable-shared --disable-static --disable-ffmpeg --disable-ffplay libavdevice configuration: --extra-version=4:0.6.1-5 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --disable-stripping --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-x11grab --enable-libdirac --enable-libfaad --enable-librtmp --enable-libdc1394 --shlibdir=/usr/lib/i686/cmov --cpu=i686 --enable-shared --disable-static --disable-ffmpeg --disable-ffplay libavfilter configuration: --extra-version=4:0.6.1-5 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --disable-stripping --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-x11grab --enable-libdirac --enable-libfaad --enable-librtmp --enable-libdc1394 --shlibdir=/usr/lib/i686/cmov --cpu=i686 --enable-shared --disable-static --disable-ffmpeg --disable-ffplay libswscale configuration: --extra-version=4:0.6.1-5 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --disable-stripping --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-x11grab --enable-libdirac --enable-libfaad --enable-librtmp --enable-libdc1394 --shlibdir=/usr/lib/i686/cmov --cpu=i686 --enable-shared --disable-static --disable-ffmpeg --disable-ffplay libpostproc configuration: --extra-version=4:0.6.1-5 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib
Bug#619530: ffmpeg: backport of 4:0.6.1-5 from unstable produces WARNING: library configuration mismatch
On Fri, 25 Mar 2011, Faheem Mitha wrote: Package: ffmpeg Version: 4:0.6.1-5 Severity: minor Hi, I backported ffmpeg 4:0.6.1-5 from unstable to squeeze. On running it, I see the following warning WARNING: library configuration mismatch inter alia. The complete output of ffmpeg is given below. I don't know if the version on unstable has the same problem, and I don't have an unstable installation handy right now to test with. However, if it does not, that makes me wonder why it should show up in a backport. I just installed the unstable version directly on squeeze. I get the same WARNING message. Regards, Faheem ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of jaaa_0.6.0-2_amd64.changes
jaaa_0.6.0-2_amd64.changes uploaded successfully to localhost along with the files: jaaa_0.6.0-2.dsc jaaa_0.6.0-2.debian.tar.gz jaaa_0.6.0-2_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/mailman/listinfo/pkg-multimedia-maintainers
