Re: packaging jack - details on plan B
On Mon, Apr 26, 2010 at 04:38:17 (CEST), Felipe Sateler wrote: On Sun, Apr 25, 2010 at 14:27, Reinhard Tartler siret...@tauware.de wrote: On Sun, Apr 25, 2010 at 19:47:47 (CEST), Jonas Smedegaard wrote: I notice, though, that above links only mention API, not ABI. Is it safe to expect library ABI (runtime linkage) to be frozen too if its API (compile time interface) is? Generally speaking, yes. (well, unless there are toolchain changes, etc. - very unlikely at this stage of squeeze) Not really. Reordering of enums, for example, could break ABI while keeping API compatibility. Same with adding/reordering struct members. Not relally common, but can happen. Oh, you're totally right. Somehow I considered these changes as API change as well, but what is meant here is a change that does not affect buildability. Other API compatible changes in C++ would e.g. include addition of additional parameters to existing methods with default parameters. This would affect ABI as well. I was clearly confused yesterday, sorry. -- 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] faac packaging branch, master, updated. debian/1.28-0fab2-11-g5313b4b
On Mon, Apr 26, 2010 at 05:34:21 (CEST), ceros-gu...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit 1cae336aff15c11be3e10e6cd25c41541aeea49c Author: Andres Mejia mcita...@gmail.com Date: Sun Apr 25 23:01:59 2010 -0400 Bump version of faac. are you willing to upload faac to debimedia? If yes, please prepare an upload and send me your ssh public key, I'll arrange access to the debimedia vserver. -- 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: packaging policy
Am 25.04.2010 19:18, schrieb Jonas Smedegaard: dh7 is not a successor for CDBS. No, but IMHO it is easier to read. I am also in favour of dh7 and dpkg-source 3.0 format, btw. 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: mplayer_1.0~rc3+svn20090426-2_amd64.changes REJECTED
Am 24.04.2010 14:03, schrieb Archive Administrator: Reject Reasons: mplayer_1.0~rc3+svn20090426-2_amd64.changes file already known to dak WTF?! -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#578500: ffmpeg depends on X related libraries
severity 578500 wishlist thanks Am 20.04.2010 12:21, schrieb Gilles Dartiguelongue: There are multiple ways of using ffmpeg without X so it would be nice to either have: * a ffmpeg-nox package * or a ffplay package (which seems to be the only util using X related * libraries) demoting severity to wishlist, as this is not really a bug. Furthermore, I won't promise we consider your request, as the ffmpeg package as it is now is already very complex and any added complexity will do more harm than cure IMHO. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging policy
On Mon, Apr 26, 2010 at 09:32:04AM +0200, Fabian Greffrath wrote: Am 25.04.2010 19:18, schrieb Jonas Smedegaard: dh7 is not a successor for CDBS. No, but IMHO it is easier to read. I do understand that some find short-form dh7 easier to read than CDBS. But is that enough reason for making it mandatory for new packages? So the (proposed) plan is to abandon CDBS, but tolerate it temporarily? - 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: packaging policy
Am 26.04.2010 09:39, schrieb Jonas Smedegaard: I do understand that some find short-form dh7 easier to read than CDBS. It's just a matter of taste. Before dh7 was introduced I was also in favour of CDBS, but the new override_* rules really got me. ;) But is that enough reason for making it mandatory for new packages? So the (proposed) plan is to abandon CDBS, but tolerate it temporarily? I think we shouldn't make anything really mandatory. IMHO it does not really help anyone but scares away the members with strong preferences for on or the other build system, e.g. Jonas. Maybe we should just *recommend* a packaging style but still tolerate the others, as they are also perfectly valid to get things done. -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging policy
On Mon, Apr 26, 2010 at 12:21:07PM +0200, Reinhard Tartler wrote: It seems that cdbs allows Jonas to be very productive, which is a great benefit for the packages he is working on. I just hope that his style of work doesn't mean that no one else but Jonas touches the package anymore. Is it really fair to draw an image of me against the World? I seem to recall others happy to use CDBS as well. Just not strongly agitating about it, as I am. - 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
Bug#457272: status update
packaging is currently on git.debian.org http://git.debian.org/?p=pkg-multimedia/dvbcut.git;a=summary But I currently don't have the time (and interest) to finally upload it to debian. It seems that an ubuntu user called 'bojo42' has updated the packaging in his PPA: https://launchpad.net/~bojo42/+archive/dvbcut Next steps would be to update to integrate this work into the pkg-multimedia packaging branch and eventually upload it to debian. -- 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: packaging policy
Am 26.04.2010 13:01, schrieb Jonas Smedegaard: Is it really fair to draw an image of me against the World? I seem to recall others happy to use CDBS as well. Just not strongly agitating about it, as I am. Erm, I have understood Reinhard speaking *for* you, not against you! But to be honest, it seems you are really the only one who makes his involvement in package maintenance dependent on the packaging system... -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: mplayer_1.0~rc3+svn20090426-2_amd64.changes REJECTED
On Mon, Apr 26, 2010 at 12:22:14 (CEST), Reinhard Tartler wrote: On Mon, Apr 26, 2010 at 09:32:17 (CEST), Fabian Greffrath wrote: Am 24.04.2010 14:03, schrieb Archive Administrator: Reject Reasons: mplayer_1.0~rc3+svn20090426-2_amd64.changes file already known to dak WTF?! Stefano asked me to do another mplayer upload Clarification: Stefano did not ask me to do anything. He rather explained me that I was wrong with my assumption that there was no way to update the mplayer package in unstable without intervention from ftp-master. Sorry for any confusion this may has caused. -- 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
Bug#579237: jack-audio-connection-kit - FTBFS: error: FFADO driver was explicitly requested but cannot be built
Source: jack-audio-connection-kit Version: 1.9.5~dfsg-2 Severity: serious There was an error while trying to autobuild your package: sbuild (Debian sbuild) 0.60.0 (23 Feb 2010) on lxdebian.bfinv.de [...] Linux detected Checking for program g++,c++ : ok /usr/bin/g++ Checking for program cpp : ok /usr/bin/cpp Checking for program ar : ok /usr/bin/ar Checking for program ranlib : ok /usr/bin/ranlib Checking for g++ : ok Checking for program gcc,cc : ok /usr/bin/gcc Checking for gcc : ok Checking for header samplerate.h : ok Checking for alsa = 1.0.18 : ok Checking for libfreebob = 1.0.0 : fail Checking for libffado = 1.999.17: fail error: FFADO driver was explicitly requested but cannot be built make: *** [debian/stamp-waf-configure] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging policy
On Mon, Apr 26, 2010 at 01:05:33PM +0200, Fabian Greffrath wrote: Am 26.04.2010 13:01, schrieb Jonas Smedegaard: Is it really fair to draw an image of me against the World? I seem to recall others happy to use CDBS as well. Just not strongly agitating about it, as I am. Erm, I have understood Reinhard speaking *for* you, not against you! What you - singular or plural? Did you somehow read it as speaking for all those interested in CDBS? But to be honest, it seems you are really the only one who makes his involvement in package maintenance dependent on the packaging system... That is my impression too. That's the agitation that I wrote about myself just above. I find it wrong, however, for this discussion to be about me vs. the rest of the world, as the issue really shouldn't be about agitation or not, but about choice of packaging style or not. Let me repeat the part that I find relevant to focus on: I seem to recall others happy to use CDBS as well. Am I imagining? Am I wrong in trying to steer the topic away from being personal? Kind regards, - 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: packaging policy
On Mon, Apr 26, 2010 at 13:05:33 (CEST), Fabian Greffrath wrote: Am 26.04.2010 13:01, schrieb Jonas Smedegaard: Is it really fair to draw an image of me against the World? I seem to recall others happy to use CDBS as well. Just not strongly agitating about it, as I am. Erm, I have understood Reinhard speaking *for* you, not against you! Indeed! And btw, the jack package was using CDBS before Jonas started working on it, which I take as clear evidence that cdbs is preferred by a couple of team members, not only by Jonas! -- 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: packaging jack - details on plan B
On Sun, 25 Apr 2010, Jonas Smedegaard wrote: I notice, though, that above links only mention API, not ABI. Is it safe to expect library ABI (runtime linkage) to be frozen too if its API (compile time interface) is? Answer from upstream: Date: Mon, 26 Apr 2010 09:34:26 -0400 From: Paul Davis p...@linuxaudiosystems.com To: Gabriel M. Beddingfield gabrb...@gmail.com Cc: Jack-Devel jack-de...@lists.jackaudio.org Subject: Re: [Jack-Devel] packaging jack - details on plan B (fwd) On Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield gabrb...@gmail.com wrote: Jack Devs: Please see the below e-mail (from debian packaging list) where Jonas would like a clarification about Jack's ABI compatability. I'm sure the answer is yes... but I wanted to check with you guys one more time. he asked I notice, though, that above links only mention API, not ABI. Is it safe to expect library ABI (runtime linkage) to be frozen too if its API (compile time interface) is? I think that the answer is yes. Certainly I am not aware of any cses where switching from one version of JACK to another has caused ABI issues. We've never had it as a hard, explicit rule that development would follow this rule, but its always been an implicit goal and is a fairly natural consequence of the development pattern for JACK. again, this clearly only applies in the upward case - ABI back-compatibility has never been assured - if a program was linked against JACK API M.N.m and the runtime installation is a version earlier than that, there may be problems as you noted. the new rules on weak symbols post the 0.118.0 API should help address this. --p ___ 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 Mon, Apr 26, 2010 at 08:29:40AM -0500, Gabriel M. Beddingfield wrote: On Sun, 25 Apr 2010, Jonas Smedegaard wrote: I notice, though, that above links only mention API, not ABI. Is it safe to expect library ABI (runtime linkage) to be frozen too if its API (compile time interface) is? I'm sure that the answer is yes, but I've asked the upstream devs to confirm it. Cool! - 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: packaging policy
Am 26.04.2010 16:16, schrieb Jonas Smedegaard: What I meant to say was that I seem to recall other _in_this_team_ happy to use CDBS as well. As Reinhard pointed out too. Alright. What I questioned was a wording by Benjamin Drung that could only (to me) be interpreted as in this team we are phasing out CDBS - new packages must use dh7 while older ones need not be converted right now. I still question that. I do not find that the wording is an attack on me or my personal style of packaging, but rather that it is narrowing the options of packaging. I agree with you. We should neither restrict the use of packaging tools too much nor should we declare one of them as deprecated and plan to replace perfectly working solutions with other ones just because they do not fit into the scheme. Yes, I agree that new contributors are helped by a set of best packaging practices. But I disagree that mandating specific tools are all helpful. Agreed. Examples: * we do code review, so please commit in sensible chunks * most of us use short-form dh7, some use CDBS * we use git-buildpackage with separate DEP3-hinted patches With the above, I bet new contributors would choose short-form dh7 unless already decided on CDBS, simply because we clearly describe how likely it is to get help using either style. Similarly a newcomer would probably think twice before insisting on using e.g. Darcs since that would be alien to the team (no matter if some in the team use Darcs in some other contexts). I find this idea really, really good. We should document what most of us do already use and not dictate others what they should use. I, personally, have no problem with a new contributor adding a package using darcs, but I will happily ignore any request for comments on this package. Exactly this should be documented. Thanks Jonas. -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ 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 Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield gabrb...@gmail.com wrote: ABI back-compatibility has never been assured - if a program was linked against JACK API M.N.m and the runtime installation is a version earlier than that, there may be problems as you noted. the new rules on weak symbols post the 0.118.0 API should help address this. Do I understand above correctly so that in fact jackd2 1.9.5 cannot be trusted to support library API (and ABI) of 0.116.2 but only that of 0.118.0? Tell me if better that I ask upstream such questions. For now I would prefer this list acting as proxy for my perhaps too silly[1] questions. - Jonas [1] No question is too silly to be asked, I know. But some might be silly enough that others than busy upstream developers can answer. :-) -- * 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: packaging jack - details on plan B
On Mon, 26 Apr 2010, Jonas Smedegaard wrote: On Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield gabrb...@gmail.com wrote: ABI back-compatibility has never been assured - if a program was linked against JACK API M.N.m and the runtime installation is a version earlier than that, there may be problems as you noted. the new rules on weak symbols post the 0.118.0 API should help address this. Do I understand above correctly so that in fact jackd2 1.9.5 cannot be trusted to support library API (and ABI) of 0.116.2 but only that of 0.118.0? Correct. If you compiled against the libs from 0.100.0, 0.109.0, 0.116.2, 0.118.0, etc. it will work fine with 1.9.5. If you compiled against the libs from 1.9.5, it will work fine with = 0.118.0. -gabriel ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging policy
Am Montag, den 26.04.2010, 16:16 +0200 schrieb Jonas Smedegaard: On Mon, Apr 26, 2010 at 03:05:18PM +0200, Fabian Greffrath wrote: Am 26.04.2010 14:43, schrieb Jonas Smedegaard: I seem to recall others happy to use CDBS as well. Yes, of course. CDBS is widely used and accepted. What I meant to say was that I seem to recall other _in_this_team_ happy to use CDBS as well. As Reinhard pointed out too. It is just that we wanted to agree upon a packaging style that we as a team can recommend to new contributors. What I questioned was a wording by Benjamin Drung that could only (to me) be interpreted as in this team we are phasing out CDBS - new packages must use dh7 while older ones need not be converted right now. I still question that. The interpretation is correct. We do not agree on that as the discussion shows. That's fine. We could either recommend dh7 or document the packaging patterns described below by Jonas. I do not find that the wording is an attack on me or my personal style of packaging, but rather that it is narrowing the options of packaging. Yes, I agree that new contributors are helped by a set of best packaging practices. But I disagree that mandating specific tools are all helpful. I was a new contributor too just a month or two ago, and I was helped by this team not being too restrictive. What I would find the most helpful was to document main patterns of our actual packaging work: This would serve both as technical introductions for beginners and as social hinting for more experienced developers (we do want to attract both, right?). Examples: * we do code review, so please commit in sensible chunks * most of us use short-form dh7, some use CDBS * we use git-buildpackage with separate DEP3-hinted patches With the above, I bet new contributors would choose short-form dh7 unless already decided on CDBS, simply because we clearly describe how likely it is to get help using either style. Similarly a newcomer would probably think twice before insisting on using e.g. Darcs since that would be alien to the team (no matter if some in the team use Darcs in some other contexts). That's the least enforcing method. This list comes to my mind: * we do code review, so please commit in sensible chunks * most of us use short-form dh7, some use CDBS * we use git as version control system * we use separate DEP3-hinted patches How to describe the 3.0 source migration? Do we recommend DEP-5? Do we wrap lists in debian/control (for example, Build-Depends)? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging policy
On Mon, Apr 26, 2010 at 04:45:43PM +0200, Benjamin Drung wrote: We could either recommend dh7 or document the packaging patterns described below by Jonas. What I would find the most helpful was to document main patterns of our actual packaging work: This would serve both as technical introductions for beginners and as social hinting for more experienced developers (we do want to attract both, right?). Examples: * we do code review, so please commit in sensible chunks * most of us use short-form dh7, some use CDBS * we use git-buildpackage with separate DEP3-hinted patches With the above, I bet new contributors would choose short-form dh7 unless already decided on CDBS, simply because we clearly describe how likely it is to get help using either style. Similarly a newcomer would probably think twice before insisting on using e.g. Darcs since that would be alien to the team (no matter if some in the team use Darcs in some other contexts). That's the least enforcing method. This list comes to my mind: * we do code review, so please commit in sensible chunks * most of us use short-form dh7, some use CDBS * we use git as version control system * we use separate DEP3-hinted patches Yes, better to separate those last, separate issues (I do tend to write very compact - thanks for loosening up!). How to describe the 3.0 source migration? It is my impression that we have not yet fully decided on that. So perhaps simply state our current uncertainty: * Some packages use source format 3.0 (quilt) despite quirks with git, some explicitly use format 1.0, but most do not yet use either ...which triggers another idea: Let's talk about patterns of _packages_ rather than us developers, as we do (ideally) work on them as a team, right? ;-) Do we recommend DEP-5? Personally I find it really great. Anyone not liking it, please speak up - not so as to discuss it now (I suggest), but rather so as to correctly document that we represent multiple opinions on this issue. Do we wrap lists in debian/control (for example, Build-Depends)? It is new to me - I had seen it before but you guys made me reflect on it and have now made CDBS do it by default. In other words: I love it! I do not like long indentations, though. I propose that we recommend wrapping with comma+newline+one-single-space. - 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: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)
Hi! Il 25/04/2010 17.33, Jonas Smedegaard ha scritto: jack-audio-connection-kit (1.9.5~dfsg-1) unstable; urgency=low . [ Jonas Smedegaard ] * Use system waf. Build-depend on waf. - Strip binary waf file (too risky to blindly invoke, and too much hassle unpacking and inspecting properly). I'm trying to remove waf from Debian (see [1]), and this package is the last one still build-depending on it. Could you please undo this change? Regards, [1] http://lists.debian.org/debian-devel/2010/02/msg00714.html -- .''`. : :' : Luca Falavigna dktrkr...@debian.org `. `' `- 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
gmusicbrowser 1.0.2-2 MIGRATED to testing
FYI: The status of the gmusicbrowser source package in Debian's testing distribution has changed. Previous version: 1.0.2-1 Current version: 1.0.2-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)
Hi Luca, On Mon, Apr 26, 2010 at 05:52:34PM +0200, Luca Falavigna wrote: Il 25/04/2010 17.33, Jonas Smedegaard ha scritto: jack-audio-connection-kit (1.9.5~dfsg-1) unstable; urgency=low . [ Jonas Smedegaard ] * Use system waf. Build-depend on waf. - Strip binary waf file (too risky to blindly invoke, and too much hassle unpacking and inspecting properly). I'm trying to remove waf from Debian (see [1]), and this package is the last one still build-depending on it. Could you please undo this change? I want to, just haven't figured out yet a way to use the shipped waf in a way that I can trust: I really do not want to blindly execute an upstream-shipped binary chunk. yes, I am aware that it is not really a binary blob but a self-extracting tarball of some kind, just haven't figured out a way to script unpacking it and verifying if its content is sane. Would you perhaps happen to know of an elegant approach? Or maybe you have a list of prior users of your waf package so that I can go examine those myself (and hope that what I find is not horrible relaxed execution everywhere)? Kind regards, - 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: raise severity of usertag drop-versioned-libjack bugs
On Mon, Apr 26, 2010 at 01:16, Jonas Smedegaard jo...@jones.dk wrote: Hi, Our JACK packaging has now contains jackd2 (no longer jackd1). Upstream has promised a frozen library API[1] equal to that of jackd1 0.116.2, and both shlibs file and symbols[2] file reflect that. The library packages no longer provide packwards compatibility with libjack0.100.0-dev. The following packages dependend on that and are now broken is unstable: Why? There is no harm in keeping libjack0.100.0-dev. -- 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: raise severity of usertag drop-versioned-libjack bugs
On Mon, Apr 26, 2010 at 01:20:16PM -0400, Felipe Sateler wrote: On Mon, Apr 26, 2010 at 01:16, Jonas Smedegaard jo...@jones.dk wrote: Hi, Our JACK packaging has now contains jackd2 (no longer jackd1). Upstream has promised a frozen library API[1] equal to that of jackd1 0.116.2, and both shlibs file and symbols[2] file reflect that. The library packages no longer provide packwards compatibility with libjack0.100.0-dev. The following packages dependend on that and are now broken is unstable: Why? There is no harm in keeping libjack0.100.0-dev. You are right: I confused ABI with API. I'll add back that virtual package which was apparently dropped accidentally - when posting before I had only discovered and reflected on what to do about it (with wrong outcome - thanks for correcting!). - 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: packaging policy
Am Montag, den 26.04.2010, 17:45 +0200 schrieb Jonas Smedegaard: Do we wrap lists in debian/control (for example, Build-Depends)? It is new to me - I had seen it before but you guys made me reflect on it and have now made CDBS do it by default. In other words: I love it! I do not like long indentations, though. I propose that we recommend wrapping with comma+newline+one-single-space. I prefer the long indentations to have all items below the first one. This make the affiliation more visible, because of the different width of the indentation. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)
Il giorno Mon, 26 Apr 2010 18:39:40 +0200 Jonas Smedegaard jo...@jones.dk ha scritto: I want to, just haven't figured out yet a way to use the shipped waf in a way that I can trust: I really do not want to blindly execute an upstream-shipped binary chunk. yes, I am aware that it is not really a binary blob but a self-extracting tarball of some kind, just haven't figured out a way to script unpacking it and verifying if its content is sane. Upstream does not even provide a way to unpack bundle bzip2 archive, that's another weak point of it. It creates a .waf-version-something directory in your root folder (e.g, jack-audio-connection-kit has .waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6, as you can also see in http://git.debian.org/?p=pkg-multimedia/jack-audio-connection-kit.git;a=tree) There you will wind wafadmin directory (which has .py files waf relies on to run) and t.bz2 (which ships some environment black magic). Would you perhaps happen to know of an elegant approach? Or maybe you have a list of prior users of your waf package so that I can go examine those myself (and hope that what I find is not horrible relaxed execution everywhere)? No, it's waf design fault. Elegant approach is providing a system-wide installation package, but upstream doesn't like it and blames us instead for his bugs. That's crazy! :) You could try this approach if you feel so (I could provide a patch): * run ./waf --version (to create .waf-version-something dir) * move .waf-version-something/wafadmin to $(CURDIR) * remove .waf-version-something * do some sed to remove bundle bzip2 archive from waf, and store the remaining bits to waf-light script * patch waf-light to understand wafadmin directory in $(CURDIR) Please let me know, Thanks! -- .''`. : :' : Luca Falavigna dktrkr...@debian.org `. `' `- signature.asc 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: packaging policy
On Mon, Apr 26, 2010 at 08:16:29PM +0200, Benjamin Drung wrote: Am Montag, den 26.04.2010, 17:45 +0200 schrieb Jonas Smedegaard: Do we wrap lists in debian/control (for example, Build-Depends)? It is new to me - I had seen it before but you guys made me reflect on it and have now made CDBS do it by default. In other words: I love it! I do not like long indentations, though. I propose that we recommend wrapping with comma+newline+one-single-space. I prefer the long indentations to have all items below the first one. This make the affiliation more visible, because of the different width of the indentation. The convention documented in Debian Policy §7.1 is single space after each comma and wrapping [...] after a comma and before the space following that comma. This is in line with other more restrictive file formats (§5.6.13, §5.6.21), which mandates single-space indentation. - 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: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)
On Mon, Apr 26, 2010 at 08:37:07PM +0200, Luca Falavigna wrote: Il giorno Mon, 26 Apr 2010 18:39:40 +0200 Jonas Smedegaard jo...@jones.dk ha scritto: I want to, just haven't figured out yet a way to use the shipped waf in a way that I can trust: I really do not want to blindly execute an upstream-shipped binary chunk. yes, I am aware that it is not really a binary blob but a self-extracting tarball of some kind, just haven't figured out a way to script unpacking it and verifying if its content is sane. Upstream does not even provide a way to unpack bundle bzip2 archive, that's another weak point of it. It creates a .waf-version-something directory in your root folder (e.g, jack-audio-connection-kit has .waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6, as you can also see in http://git.debian.org/?p=pkg-multimedia/jack-audio-connection-kit.git;a=tree) There you will wind wafadmin directory (which has .py files waf relies on to run) and t.bz2 (which ships some environment black magic). Would you perhaps happen to know of an elegant approach? Or maybe you have a list of prior users of your waf package so that I can go examine those myself (and hope that what I find is not horrible relaxed execution everywhere)? No, it's waf design fault. Elegant approach is providing a system-wide installation package, but upstream doesn't like it and blames us instead for his bugs. That's crazy! :) You could try this approach if you feel so (I could provide a patch): * run ./waf --version (to create .waf-version-something dir) * move .waf-version-something/wafadmin to $(CURDIR) * remove .waf-version-something * do some sed to remove bundle bzip2 archive from waf, and store the remaining bits to waf-light script * patch waf-light to understand wafadmin directory in $(CURDIR) Please let me know, Thanks! A patch would be awesome! I notice several multimedia projects jumping on the waf craze, so fear that we cannot simply close our eyes to this issue, and I refuse to trust invoking black magic voodoo as part of standard build routines. When figuring out a full set of routines to unpack, verify and use waf indirectly, I strongly consider adding a CDBS module to handle it - well aware that I might trigger the wrath of upstream waf developers in doing so... :-/ - 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: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)
[sent again, cc Luca this time] On Mon, Apr 26, 2010 at 08:37:07PM +0200, Luca Falavigna wrote: Il giorno Mon, 26 Apr 2010 18:39:40 +0200 Jonas Smedegaard jo...@jones.dk ha scritto: I want to, just haven't figured out yet a way to use the shipped waf in a way that I can trust: I really do not want to blindly execute an upstream-shipped binary chunk. yes, I am aware that it is not really a binary blob but a self-extracting tarball of some kind, just haven't figured out a way to script unpacking it and verifying if its content is sane. Upstream does not even provide a way to unpack bundle bzip2 archive, that's another weak point of it. It creates a .waf-version-something directory in your root folder (e.g, jack-audio-connection-kit has .waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6, as you can also see in http://git.debian.org/?p=pkg-multimedia/jack-audio-connection-kit.git;a=tree) There you will wind wafadmin directory (which has .py files waf relies on to run) and t.bz2 (which ships some environment black magic). Would you perhaps happen to know of an elegant approach? Or maybe you have a list of prior users of your waf package so that I can go examine those myself (and hope that what I find is not horrible relaxed execution everywhere)? No, it's waf design fault. Elegant approach is providing a system-wide installation package, but upstream doesn't like it and blames us instead for his bugs. That's crazy! :) You could try this approach if you feel so (I could provide a patch): * run ./waf --version (to create .waf-version-something dir) * move .waf-version-something/wafadmin to $(CURDIR) * remove .waf-version-something * do some sed to remove bundle bzip2 archive from waf, and store the remaining bits to waf-light script * patch waf-light to understand wafadmin directory in $(CURDIR) Please let me know, Thanks! A patch would be awesome! I notice several multimedia projects jumping on the waf craze, so fear that we cannot simply close our eyes to this issue, and I refuse to trust invoking black magic voodoo as part of standard build routines. When figuring out a full set of routines to unpack, verify and use waf indirectly, I strongly consider adding a CDBS module to handle it - well aware that I might trigger the wrath of upstream waf developers in doing so... :-/ - 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
Processing of jack-audio-connection-kit_1.9.5~dfsg-3_amd64.changes
jack-audio-connection-kit_1.9.5~dfsg-3_amd64.changes uploaded successfully to localhost along with the files: jack-audio-connection-kit_1.9.5~dfsg-3.dsc jack-audio-connection-kit_1.9.5~dfsg-3.debian.tar.gz jackd_1.9.5~dfsg-3_amd64.deb libjack0_1.9.5~dfsg-3_amd64.deb jackd-firewire_1.9.5~dfsg-3_amd64.deb libjack-dev_1.9.5~dfsg-3_amd64.deb Greetings, Your Debian queue daemon (running on host ries.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
jack-audio-connection-kit_1.9.5~dfsg-3_amd64.changes ACCEPTED
Accepted: jack-audio-connection-kit_1.9.5~dfsg-3.debian.tar.gz to main/j/jack-audio-connection-kit/jack-audio-connection-kit_1.9.5~dfsg-3.debian.tar.gz jack-audio-connection-kit_1.9.5~dfsg-3.dsc to main/j/jack-audio-connection-kit/jack-audio-connection-kit_1.9.5~dfsg-3.dsc jackd-firewire_1.9.5~dfsg-3_amd64.deb to main/j/jack-audio-connection-kit/jackd-firewire_1.9.5~dfsg-3_amd64.deb jackd_1.9.5~dfsg-3_amd64.deb to main/j/jack-audio-connection-kit/jackd_1.9.5~dfsg-3_amd64.deb libjack-dev_1.9.5~dfsg-3_amd64.deb to main/j/jack-audio-connection-kit/libjack-dev_1.9.5~dfsg-3_amd64.deb libjack0_1.9.5~dfsg-3_amd64.deb to main/j/jack-audio-connection-kit/libjack0_1.9.5~dfsg-3_amd64.deb Override entries for your package: jack-audio-connection-kit_1.9.5~dfsg-3.dsc - source sound jackd-firewire_1.9.5~dfsg-3_amd64.deb - optional sound jackd_1.9.5~dfsg-3_amd64.deb - optional sound libjack-dev_1.9.5~dfsg-3_amd64.deb - optional libdevel libjack0_1.9.5~dfsg-3_amd64.deb - optional libs Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 579237 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#579237: marked as done (jack-audio-connection-kit - FTBFS: error: FFADO driver was explicitly requested but cannot be built)
Your message dated Mon, 26 Apr 2010 19:36:11 + with message-id e1o6u6f-00055k...@ries.debian.org and subject line Bug#579237: fixed in jack-audio-connection-kit 1.9.5~dfsg-3 has caused the Debian Bug report #579237, regarding jack-audio-connection-kit - FTBFS: error: FFADO driver was explicitly requested but cannot be built 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.) -- 579237: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579237 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Source: jack-audio-connection-kit Version: 1.9.5~dfsg-2 Severity: serious There was an error while trying to autobuild your package: sbuild (Debian sbuild) 0.60.0 (23 Feb 2010) on lxdebian.bfinv.de [...] Linux detected Checking for program g++,c++ : ok /usr/bin/g++ Checking for program cpp : ok /usr/bin/cpp Checking for program ar : ok /usr/bin/ar Checking for program ranlib : ok /usr/bin/ranlib Checking for g++ : ok Checking for program gcc,cc : ok /usr/bin/gcc Checking for gcc : ok Checking for header samplerate.h : ok Checking for alsa = 1.0.18 : ok Checking for libfreebob = 1.0.0 : fail Checking for libffado = 1.999.17: fail error: FFADO driver was explicitly requested but cannot be built make: *** [debian/stamp-waf-configure] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 ---End Message--- ---BeginMessage--- Source: jack-audio-connection-kit Source-Version: 1.9.5~dfsg-3 We believe that the bug you reported is fixed in the latest version of jack-audio-connection-kit, which is due to be installed in the Debian FTP archive: jack-audio-connection-kit_1.9.5~dfsg-3.debian.tar.gz to main/j/jack-audio-connection-kit/jack-audio-connection-kit_1.9.5~dfsg-3.debian.tar.gz jack-audio-connection-kit_1.9.5~dfsg-3.dsc to main/j/jack-audio-connection-kit/jack-audio-connection-kit_1.9.5~dfsg-3.dsc jackd-firewire_1.9.5~dfsg-3_amd64.deb to main/j/jack-audio-connection-kit/jackd-firewire_1.9.5~dfsg-3_amd64.deb jackd_1.9.5~dfsg-3_amd64.deb to main/j/jack-audio-connection-kit/jackd_1.9.5~dfsg-3_amd64.deb libjack-dev_1.9.5~dfsg-3_amd64.deb to main/j/jack-audio-connection-kit/libjack-dev_1.9.5~dfsg-3_amd64.deb libjack0_1.9.5~dfsg-3_amd64.deb to main/j/jack-audio-connection-kit/libjack0_1.9.5~dfsg-3_amd64.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 579...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jonas Smedegaard d...@jones.dk (supplier of updated jack-audio-connection-kit package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Mon, 26 Apr 2010 20:41:50 +0200 Source: jack-audio-connection-kit Binary: jackd libjack0 jackd-firewire libjack-dev Architecture: source amd64 Version: 1.9.5~dfsg-3 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Changed-By: Jonas Smedegaard d...@jones.dk Description: jackd - JACK Audio Connection Kit (server and example clients) jackd-firewire - JACK Audio Connection Kit (FFADO and FreeBoB backends) libjack-dev - JACK Audio Connection Kit (development files) libjack0 - JACK Audio Connection Kit (libraries) Closes: 579237 Changes: jack-audio-connection-kit (1.9.5~dfsg-3) unstable; urgency=low . * Fix restructure configure options to only add --firewire on supported architectures. Closes: bug#579237, thanks to Bastian Blank. * Handle library ABI through generalized packaging variable. * Bump API to 0.118.0 (from 9.116.2): Jackd2 1.9.4 declared compliance this newer version of jackd1, and does not promise backwards compatibility. * Tighten symbols older than API version to instead follow API: Future alternative implementations potentially of older version themselves are not assured to be binary compatible. * Have libjack-dev provide virtual libjack0.100.0-dev (...again - was apparently lost at some point upgrading to jackd2). Checksums-Sha1: 6cc12db17dd6042429b78cff00632ecd63057525 1905
Re: packaging policy
Am Montag, den 26.04.2010, 20:51 +0200 schrieb Jonas Smedegaard: On Mon, Apr 26, 2010 at 08:16:29PM +0200, Benjamin Drung wrote: Am Montag, den 26.04.2010, 17:45 +0200 schrieb Jonas Smedegaard: Do we wrap lists in debian/control (for example, Build-Depends)? It is new to me - I had seen it before but you guys made me reflect on it and have now made CDBS do it by default. In other words: I love it! I do not like long indentations, though. I propose that we recommend wrapping with comma+newline+one-single-space. I prefer the long indentations to have all items below the first one. This make the affiliation more visible, because of the different width of the indentation. The convention documented in Debian Policy §7.1 is single space after each comma and wrapping [...] after a comma and before the space following that comma. §7.1 does permit multiple spaces Whitespace may appear at any point[...] This is in line with other more restrictive file formats (§5.6.13, §5.6.21), which mandates single-space indentation. In my opinion it has noting to do with §5.6.13 (Description is not a list) and §5.6.21 (Files are separated by newlines and not commas). -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging policy
On Mon, Apr 26, 2010 at 10:57:43PM +0200, Benjamin Drung wrote: Am Montag, den 26.04.2010, 20:51 +0200 schrieb Jonas Smedegaard: On Mon, Apr 26, 2010 at 08:16:29PM +0200, Benjamin Drung wrote: Am Montag, den 26.04.2010, 17:45 +0200 schrieb Jonas Smedegaard: Do we wrap lists in debian/control (for example, Build-Depends)? It is new to me - I had seen it before but you guys made me reflect on it and have now made CDBS do it by default. In other words: I love it! I do not like long indentations, though. I propose that we recommend wrapping with comma+newline+one-single-space. I prefer the long indentations to have all items below the first one. This make the affiliation more visible, because of the different width of the indentation. The convention documented in Debian Policy §7.1 is single space after each comma and wrapping [...] after a comma and before the space following that comma. §7.1 does permit multiple spaces Whitespace may appear at any point[...] Yes. That's why I wrote that it is a convention, not a requirement. This is in line with other more restrictive file formats (§5.6.13, §5.6.21), which mandates single-space indentation. In my opinion it has noting to do with §5.6.13 (Description is not a list) and §5.6.21 (Files are separated by newlines and not commas). What they have in common is pseudo-rfc822 format, I believe. We clearly disagree, and noone else have shared their opinion. I suggest we document that there is no consensus on format of multi-line lists for now. - 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: packaging policy
Am Montag, den 26.04.2010, 23:16 +0200 schrieb Jonas Smedegaard: On Mon, Apr 26, 2010 at 10:57:43PM +0200, Benjamin Drung wrote: Am Montag, den 26.04.2010, 20:51 +0200 schrieb Jonas Smedegaard: On Mon, Apr 26, 2010 at 08:16:29PM +0200, Benjamin Drung wrote: Am Montag, den 26.04.2010, 17:45 +0200 schrieb Jonas Smedegaard: Do we wrap lists in debian/control (for example, Build-Depends)? It is new to me - I had seen it before but you guys made me reflect on it and have now made CDBS do it by default. In other words: I love it! I do not like long indentations, though. I propose that we recommend wrapping with comma+newline+one-single-space. I prefer the long indentations to have all items below the first one. This make the affiliation more visible, because of the different width of the indentation. The convention documented in Debian Policy §7.1 is single space after each comma and wrapping [...] after a comma and before the space following that comma. §7.1 does permit multiple spaces Whitespace may appear at any point[...] Yes. That's why I wrote that it is a convention, not a requirement. This is in line with other more restrictive file formats (§5.6.13, §5.6.21), which mandates single-space indentation. In my opinion it has noting to do with §5.6.13 (Description is not a list) and §5.6.21 (Files are separated by newlines and not commas). What they have in common is pseudo-rfc822 format, I believe. Yes. We clearly disagree, and noone else have shared their opinion. Yes, but we agree on wrapping at least. ;) I suggest we document that there is no consensus on format of multi-line lists for now. Yes. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)
On Mon, Apr 26, 2010 at 11:44:49PM +0200, Luca Falavigna wrote: Il giorno Mon, 26 Apr 2010 20:57:44 +0200 Jonas Smedegaard jo...@jones.dk ha scritto: A patch would be awesome! Here it is: http://people.debian.org/~dktrkranz/local_waf.patch I tested it and package built. I didn't test if resulting binaries are sane, and the same applies to the build log itself. Keep in mind this is an untested, ugly hack ;) I will not have time to look at it the upcoming days, but thanks a lot! I don't mind it being ugly - I can tighten it up myself - just great to have a hack that (supposedly) works to work from :-D - 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: packaging policy
I don't like long indentations, too. IMHO, single space indentation and `comma + \n + single_space` wrapping-style increase readability. -- Alessio Treglia quadris...@ubuntu.com Ubuntu MOTU Developer | Homepage: http://www.alessiotreglia.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
