Re: [SCM] zita-convolver2 packaging branch, master, updated. debian/2.0.0-3-17-g5519e74
Od: Reinhard Tartler siret...@tauware.de I've just tested this change, and made the following observations: a) creating a source package with 'git-buildpackage -S' still leaves the working copy dirty. b) cleaning the working copy with 'debclean' works as expected, a 'git status' shows nothing to commit (working directory clean) Since debclean in a Format 1.0 and Format 3.0 (native) branch have the same effect (although they are unnecessary there), I'd say the implementation of the compromise works out. thanks! I tried solved this using 'debclean', but had dirty working copy all the time. So I used source/option file 'no-preparation' , now makefile is unpatched after 'git-buildpackage -S' running But there is new file in debian/patches 'debian-changes-2.0.0-3' and series file is changed. Is such aproach correct? I pushed changes to repo regards mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Rekindle jack implementation swapping discussion (was Re: Request to join the Debian Multimedia Team)
On Sat, May 29, 2010 at 05:06:24PM -0400, Felipe Sateler wrote: Given the tons of C++ symbols in jackd2, I'd also suggest to make the jackd1 package the official dev package and also the donator of the symbols file. I'm quite confused by this. AFAIK, jack is a pure C API, so C++ symbols have no place in there. Yep. But jackd2 is implemented in C++, and these symbols somehow are public or leak into the symbols file (also with -fvisibility=hidden). However, I understood from the last discussion that those are not really bogus, but are some sort of internal (server-lib) API, which is not allowed to be used by regular clients. Is this correct? Exactly. Anyway, I really think that for jack it is much better to use a shlibs file. I'm completely fine with a shlibs file. Makes things a lot easier. 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#583884: libva-x11-1: circular dependency with libva1
Package: libva-x11-1 Version: 1.0.1-2 Severity: important Hello Debian Multimedia Maintainers, There is a circular dependency between libva-x11-1 and libva1: libva-x11-1 :Depends: libva1 libva1 :Depends: libva-x11-1 Circular dependencies involving shared libraries are known to cause problems during upgrade, so we should try to get rid of them. See threads http://lists.debian.org/debian-devel/2005/06/msg02111.html http://lists.debian.org/debian-devel/2005/11/msg01101.html Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Jusqu'au 30 juin offre spéciale en partenariat avec nos fi chiers B2B B2C
Besoin d'un partenaire pour vos campagnes d'e-mailing ? Mailing-Pme vous propose des fichiers sur mesure, tout en prenant en charge le routage et la gestion de vos campagnes d'e-mailings ou de vos newsletters. Actualités, Promotions, Nouveaux produits, Invitations… Nous mettons à votre disposition les ressources technologiques les plus pertinentes, puissantes et néanmoins flexibles du marché afin de vous accompagner tout au long de votre développement d'entreprise. Notre mission est d'offrir à des sociétés de tailles diverses, la possibilité de survivre dans un environnement concurrentiel, et ce en leur proposant des prestations au juste prix. LOCATION DE FICHIERS OPT-IN Grâce à notre base de fichiers opt-in, c'est à dire constituée de particuliers et d'entreprises acceptant de recevoir de la publicité, nous vous aiderons à bénéficier d'une meilleure exposition internet et à développer vos ventes. %%READING_LINK%% ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#493735: libmms-dev: Incorrect use of this keyword in mmsx.h
Hi, On 05/31/2010 02:08 PM, Fabian Greffrath wrote: Hi Hans, Am 31.05.2010 12:44, schrieb Hans de Goede: This is fixed in the latest upstream release: http://downloads.sourceforge.net/project/libmms/libmms/0.6/libmms-0.6.tar.gz does the new upstream version also include the patch that adds support for extended stream properties, as requested here? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498174 Yes, not only does it contain that patch, but the patch has been ported to the mmsh code as well. The code inside libmms is split in mmst and mmsh code, and the patch linked from: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498174 Only adds extended stream properties support to the mmst handling code, I later ported this to the mmsh code as well. Thanks for the link to the debian bug, now I've an uri to actually test this, and ... it works :) Regards, Hans p.s. 0.6 is fully ABI compatible with 0.4, so its a drop in replacement with many bugfixes. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Rekindle jack implementation swapping discussion
On Mo, Mai 31, 2010 at 11:18:55 (CEST), Adrian Knoth wrote:
On Sat, May 29, 2010 at 05:06:24PM -0400, Felipe Sateler wrote:
Given the tons of C++ symbols in jackd2, I'd also suggest to make the
jackd1 package the official dev package and also the donator of the
symbols file.
I'm quite confused by this. AFAIK, jack is a pure C API, so C++
symbols have no place in there.
Yep. But jackd2 is implemented in C++, and these symbols somehow are
public or leak into the symbols file (also with -fvisibility=hidden).
May I summarize this as:
We intend to ship two implementations of jack:
One that is used to build applications and one that we intend users to
use as default.
Is this a basis for consebsus?
However, I understood from the last discussion that those are not
really bogus, but are some sort of internal (server-lib) API, which is
not allowed to be used by regular clients. Is this correct?
Exactly.
Anyway, I really think that for jack it is much better to use a shlibs
file.
I'm completely fine with a shlibs file. Makes things a lot easier.
Okay.
Proposed wording for the release team:
Dear Release Team,
We, the pkg-multimedia team, would like to announce our intend to start
a (new) jack transition. This includes a new upload of the package
'jack-audio-connection-kit', which provides the packages libjack0 and
libjack-dev.
Details follow:
There are several implementations of the jack audio connection kit.
Besides the version which was included in Debian Lenny ('jackd'), there
are also a number of different other implementations that partly offer a
number of additional and (in our opinion) important features. All newer
jack implementations are intended to be binary-compatible drop-in
replacements the the original jackd.
The last transition has switched the jack-audio-connection-kit package
from 'jackd' to 'jackd2'. 'jackd2' is a complete reimplementation of
jackd in C++ with SMP support. Most importantly however, is a added
feature that improves interoperability with pulseaudio. For this
reason, we decided to make this version the default version for Squeeze.
During testing, however, we discovered that this transition has been and
still is a bit problematic. Besides some more or less known bugs in
'jackd2', it exposes a lot of additional (internal, c++ only) symbols,
with which we are not comfortable at all. Moreover, we have been
approached by upstream(s) with concerns that our current package does
not make it easy for 3rd parties (may it be upstream or backports.org)
to provide replacement packages for other jackd implementations.
For this reason, we propose to:
- revert the 'jack-audio-connection-kit' package to the jackd1
implementation
- make this package the provider of libjack-dev, however the actual
daemon will be packaged as 'jackd1' (currently jackd)
- create a shlibs file that makes application packages to depend on
'libjack0-0.116 | (= libjack0-0.118+svn3796)'. This effectively
defines a new virtual package 'libjack0-0.116' that is provided by
any jack implementations that claims to be binary compatible with the
0.116 release of the original jack implementation.
- have all packages that are linked against libjack recompiled to pick
up the new shlibs
- introduce the jackd2 implementation as new source package 'jackd2'.
The binary package name of this jack daemon will be 'jackd2', the
library package will be 'libjack-jackd2-0' and (of course also)
provide 'libjack0-0.116'.
- introduce a new source package 'jackd-defaults' that provides a meta
package 'jackd' which points to the default jack implementation,
which will be jackd2 for Debian.
This creates the situation that we actually partially revert the last
transition. However, we still consider jackd2 as the superior
implementation for squeeze, so we need to introduce a new virtual
package for the libjack0 library. We expect the actual rebuilds to be
rather smooth, since the jackd1 implementation was tested extensively in
Lenny and squeeze.
We know that this is very very late for squeeze for which we apologize,
but hope that it's not too late yet. Please give us a timeframe when we
can start this transition with a new 'jack-audio-connection-kit' upload.
on behalf of pkg-multimedia,
...
proposed wording end.
What do you think about this? With this explanation, I think the actual
implementation in the source package should be straight-forward.
--
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: Rekindle jack implementation swapping discussion
On Mon, May 31, 2010 at 03:01:14PM +0200, Reinhard Tartler wrote: May I summarize this as: We intend to ship two implementations of jack: One that is used to build applications and one that we intend users to use as default. Is this a basis for consebsus? ACK. Proposed wording for the release team: [..] number of additional and (in our opinion) important features. All newer jack implementations are intended to be binary-compatible drop-in replacements the the original jackd. ^^^ to Anything else is fine. Thanks for your efforts. -- 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#493735: libmms-dev: Incorrect use of this keyword in mmsx.h
Am 31.05.2010 14:14, schrieb Hans de Goede: Only adds extended stream properties support to the mmst handling code, I later ported this to the mmsh code as well. Thanks for the link to the debian bug, now I've an uri to actually test this, and ... it works :) That's very good news, thanks! 0.6 is fully ABI compatible with 0.4, so its a drop in replacement with many bugfixes. Since this would have been my next question, anyway, that's even better news. ;) IMHO these are enough reasons to upgrade to the new library version in Debian. However, I'd like to give Arthur the chance to do so before I get active myself. Cheers, Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Rekindle jack implementation swapping discussion
On Mo, Mai 31, 2010 at 15:10:31 (CEST), Adrian Knoth wrote: Thanks for your efforts. edrz has put the text on whitebard: http://whiteboard.debian.net/jackd_transition.wb I'd prefer if someone from the jack doers would send the text, but if everyone is too busy, I'd do it in a few hours, because it was announced that the transition freeze would start end of may (which is *today*) and all transition had to be announced before May 21st. I'll edit the whiteboard with the bug number as soon as I have it. -- 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
libmpc_0.1~r459-1_amd64.changes ACCEPTED
Accepted: libmpc_0.1~r459-1.debian.tar.gz to main/libm/libmpc/libmpc_0.1~r459-1.debian.tar.gz libmpc_0.1~r459-1.dsc to main/libm/libmpc/libmpc_0.1~r459-1.dsc libmpc_0.1~r459.orig.tar.gz to main/libm/libmpc/libmpc_0.1~r459.orig.tar.gz libmpcdec-dev_0.1~r459-1_amd64.deb to main/libm/libmpc/libmpcdec-dev_0.1~r459-1_amd64.deb libmpcdec6_0.1~r459-1_amd64.deb to main/libm/libmpc/libmpcdec6_0.1~r459-1_amd64.deb musepack-tools_0.1~r459-1_amd64.deb to main/libm/libmpc/musepack-tools_0.1~r459-1_amd64.deb Override entries for your package: libmpc_0.1~r459-1.dsc - source sound libmpcdec-dev_0.1~r459-1_amd64.deb - optional libdevel libmpcdec6_0.1~r459-1_amd64.deb - optional libs musepack-tools_0.1~r459-1_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
Re: Rekindle jack implementation swapping discussion (was Re: Request to join the Debian Multimedia Team)
On Mon, May 31, 2010 at 05:18, Adrian Knoth a...@drcomp.erfurt.thur.de wrote: On Sat, May 29, 2010 at 05:06:24PM -0400, Felipe Sateler wrote: Given the tons of C++ symbols in jackd2, I'd also suggest to make the jackd1 package the official dev package and also the donator of the symbols file. I'm quite confused by this. AFAIK, jack is a pure C API, so C++ symbols have no place in there. Yep. But jackd2 is implemented in C++, and these symbols somehow are public or leak into the symbols file (also with -fvisibility=hidden). These symbols are being explicitly exported (check the header files). See below. However, I understood from the last discussion that those are not really bogus, but are some sort of internal (server-lib) API, which is not allowed to be used by regular clients. Is this correct? Exactly. The symbols cannot then be hidden (otherwise the server will not find them). So they will be a noise factor _forever_. I'm wondering if this is a correct design decision (having a single library for both a public and a private API), but it's not my call to make. I think we should trust upstream and just shove a libjack0.shlibs with =0.116, and be done with it. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Rekindle jack implementation swapping discussion
On Mon, May 31, 2010 at 09:01, Reinhard Tartler siret...@tauware.de wrote: - create a shlibs file that makes application packages to depend on 'libjack0-0.116 | (= libjack0-0.118+svn3796)'. This effectively defines a new virtual package 'libjack0-0.116' that is provided by any jack implementations that claims to be binary compatible with the 0.116 release of the original jack implementation. I'm confused by the shlibs snippet. Shouldn't it be (and it isn't correct on the current whiteboard either): libjack0-0.116 | libjack0 (= 1:0.116)? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] zita-convolver2 packaging branch, master, updated. debian/2.0.0-3-17-g5519e74
Od: Reinhard Tartler siret...@tauware.de Since debclean in a Format 1.0 and Format 3.0 (native) branch have the same effect (although they are unnecessary there), I'd say the implementation of the compromise works out. Format 3.0 (native) that is what I omitted ... it works fine here with debclean But format 3.0 (native) doesn't generate orig.tar.bz2 from pristine-tar mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
