Re: [SCM] pd-pmpd packaging branch, master, updated. upstream/0.9-4-g86cd593
On Tue, Aug 24, 2010 at 00:22:50 (CEST), Hans-Christoph Steiner wrote: On Aug 22, 2010, at 2:20 PM, Jonas Smedegaard wrote: On Sat, Aug 21, 2010 at 08:18:24PM -0400, Felipe Sateler wrote: On 21/08/10 18:00, eighthave-gu...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit b50fc79d8a856062d9a05100dd83a7fca3bf696b Author: Hans-Christoph Steiner h...@eds.org Date: Sat Aug 21 17:43:50 2010 -0400 added gitignore for clean git-status diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..3c2f99e --- /dev/null +++ b/.gitignore @@ -0,0 +1,7 @@ +debian/files +debian/pd-pmpd.debhelper.log +debian/pd-pmpd.substvars +debian/pd-pmpd/ +*.o +*.pd_linux +.pc I can't think of any reason not to do this... but we don't seem to have this in any of our other packages (or at least, most). Any reason why we haven't done this before? I dislike silencing cruft, as in my packaging development routines cruft is a sign of something potentially forgotten or gone wrong: A normal packaging build and successive cleanup should leave no traces behind[1]. Sounds reasonable. I don't have a strong opinion, so I am happy to remove the .gitignore if you think I should. I think ignoring the .pc directory is okay. We also (have to) tolerate the existance of .git after all. -- 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] multicat packaging branch, pristine-tar, created. 8310c858374a1a6643c1e22ade6ba88f1e61351f
On Mon, Aug 23, 2010 at 11:11 PM, ivoire-gu...@users.alioth.debian.org wrote: The branch, pristine-tar has been created at 8310c858374a1a6643c1e22ade6ba88f1e61351f (commit) - Shortlog commit 8310c858374a1a6643c1e22ade6ba88f1e61351f Author: Rémi Duraffort ivo...@videolan.org Date: Mon Aug 23 23:05:09 2010 +0200 pristine-tar data for multicat-1.0.tar.bz2 --- Looks interesting to me, you've already found a sponsor if you need. Thanks, the package need some more polishing but I guess it will be ready soon. -- Rémi Duraffort | ivoire http://ivoire.dinauz.org/blog/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Adopting jack-tools
On Mon, Aug 23, 2010 at 7:57 PM, Arnout Engelen arnou...@bzzt.net wrote: In the mean time, anything else I can do to get the package in shape for sponsorship? We should wait for a response from upstream first. -- Alessio Treglia ales...@alessiotreglia.com Debian Ubuntu 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
Processing of multicat_1.0-1_i386.changes
multicat_1.0-1_i386.changes uploaded successfully to localhost along with the files: multicat_1.0-1.dsc multicat_1.0.orig.tar.bz2 multicat_1.0-1.debian.tar.gz multicat_1.0-1_i386.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
Re: pd-zexy compilation improvements
On Mon, Aug 23, 2010 at 10:32:55AM +0200, IOhannes m zmoelnig wrote: On 2010-08-23 09:58, Reinhard Tartler wrote: If they are indeed in non-standard paths such that the dynamic linker doesn't see it without setting LD_LIBRARY_PATH or similar, then you're right. But.. nevertheless, it complies with it... even on amd64? There are some architectures that are pretty picky about position independent code. BTW that's why there is this rule in debian policy in the first place. pd-zexy compiles everything with -fPIC an ALL (including amd64) platforms[1]. the discussion arose, because jonas wanted it to be compiled withOUT -fPIC (which is in contradiction to the debian policy afaict) do i get something wrong? No - I had it upside down. Lucky you are upstream, not me, as it seems you actually know what you are talking about ;-) - 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: pd-zexy compilation improvements
On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote: On 2010-08-22 20:06, Jonas Smedegaard wrote: Indeed this looks weird. If you consider it sane to use this approach then I guess it won't matter much. But striving towards the ultimate, if this is a dirty hack then please elaborate on possible alternative approaches - even if tricky to achieve: others here might have ideas on how to reach a higher level of elegantry (or however that word is bent). it's certainly in sync with the current puredata package in debian; the relevant patches (using the pd_linux extension for debian/hurd and debian/kFreeBSD) have even made it into upstream of puredata other pkgs usually use .so as extension, which Pd for historical reasons does not, and instead uses it's own extension (varying across platforms). Hmm. Do we then perhaps need to beware of this for helper tools like lintian and dh_shlibdeps? I actually do not think that dh_shlibdeps has any role here, just mentioning it as an example: For Debian packaging we have a bunch of helper tools used either directly during packaging or during various tests and inspections, which rely on e.g. shared libraries ending in .so and located below /usr/lib. When then unusual things are done, we might want to add hints for such tools to not hide potential problems from them. Or expressed differently: Even if PureData works splendid with its unusual naming, we still might benefit in Debian (and derivatives) from using the classic .so extension if indeed it is technically the same. One example issue we could be hiding is that of rpath usage: Everything works fine but Debian set higher standards than works fine for *normal* use and lintian checks was added at some point to warn if rpath was used in shared libraries. Again, I do not say that rpath in particular is my concern - it is but an example: Could be some other similarly pedantic issue raised later, which none of us today know about, but will remain hidden if we use odd naming for a common file type. Also, some archs have problems with fPIC, and I believe it is mentioned in Debian Policy that normal builds should *not* use fPIC while static libraries (unused here, just mentioning for completenes sake) *should* use it. the fPIC flag is tested for during configure time, and it's only used if the compiler supports it. it was introduced, because x86_64 does require it. it can be turned off by using --disable-PIC, though of course this has to exclude x86_64 Do others have more knowledge about this than me? this sounds a bit ironic, but i miss the smiley, so i guess it's not. It is not: I know Make, Perl, Bash, love regular expressions, and can juggle patches. But cannot do a helloworld in C or C++. It takes more than a smiley to change that :-) NB! Please do not cc me - I am subscribed, and it messes up my MUA. - 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
doxygen issue solved!
Hi, Not directly related to this team, but since we have been affected by it and also discussed hardcoding workarounds in some of our packages: Apparently the issue of doxygen failing on some archs have been solved now: doxygen (1.7.1-2) unstable; urgency=low * Don't use threads for the `dot' runs (Petr Salinger). Closes: #591648, #593317. I believe we should remove any quirks specifically working around this issue. We should not, however, revert changes to compile documentation only in arch-all (as I believe was the case with csound). - 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
Hello
Hello How are you today? I Hope you are fine in good health. I saw your email searches and admire it, I deemed it necessary you immediately.I appreciate you to reciprocate to by dropping on my mail so that we will introduce ourself better and share the passionate of love. I will be waiting for your email for more details because i have something suitable to tell you. Have a nice day, Best Regards. Amina ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of calf_0.0.18.6-1_i386.changes
calf_0.0.18.6-1_i386.changes uploaded successfully to localhost along with the files: calf_0.0.18.6-1.dsc calf_0.0.18.6.orig.tar.gz calf_0.0.18.6-1.debian.tar.gz calf-plugins_0.0.18.6-1_i386.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
calf_0.0.18.6-1_i386.changes REJECTED
Reject Reasons: a...@drcomp.erfurt.thur.de (A7830CCABA4AFF02E50213FE8F32B4422F52107F) is not authorised to sponsor uploads === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] calf audio plugins packaging branch, master, updated. debian/0.0.18.5-1-13-g1771d8e
On Tue, Aug 24, 2010 at 04:06:41PM +, adiknoth-gu...@users.alioth.debian.org wrote: + [ Jonas Smedegaard ] + * Tidy copyright file: Adjust a few stanzas and declare it formatted +according to draft DEP5 rev135. + * Fix add a missed owner to copyright file (no new licenses). + * Drop local CDBS snippets and locally declared DEB_MAINTAINER_MODE: +All part of main CDBS now. + * Refer to FSF website (not postal address) in rules file header. + * Fix ALSA build-dependency auto-resolving (CDBS no longer horribly +executes control.in file as a shell script). + * Improve watch file: Add usage comment; relax pattern to non-digit +versions and non-gzip tarball compression. + * Fix DEP5 synatx of copyright file: append ./ in all files sections. + * Improve copyright file: Refer to FSF website (not postal address), +and put reference below Debian-specific comment to hint that it is +not verbatim copied. Please another time look at possibilities of merging entries when doing git-dch. I would have merged and compacted the multiple changes to copyright file in above. 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: [SCM] calf audio plugins packaging branch, master, updated. debian/0.0.18.5-1-13-g1771d8e
On Tue, Aug 24, 2010 at 04:06:39PM +, adiknoth-gu...@users.alioth.debian.org wrote: Bump standards version diff --git a/debian/control b/debian/control [snip diff --git a/debian/control.in b/debian/control.in Please separate commits of manual edits from automated ones. That improves ability to later revert or reuse across branches. If you are not interested in messing with CDBS, then please simply avoid messing with that .in file at all - leave that for others to re-apply the changes there later. :-) 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: [SCM] calf audio plugins packaging branch, master, updated. debian/0.0.18.5-1-13-g1771d8e
On Tue, Aug 24, 2010 at 06:16:24PM +0200, Jonas Smedegaard wrote: + [ Jonas Smedegaard ] + * Tidy copyright file: Adjust a few stanzas and declare it formatted +according to draft DEP5 rev135. + * Fix add a missed owner to copyright file (no new licenses). + * Drop local CDBS snippets and locally declared DEB_MAINTAINER_MODE: +All part of main CDBS now. + * Refer to FSF website (not postal address) in rules file header. + * Fix ALSA build-dependency auto-resolving (CDBS no longer horribly +executes control.in file as a shell script). + * Improve watch file: Add usage comment; relax pattern to non-digit +versions and non-gzip tarball compression. + * Fix DEP5 synatx of copyright file: append ./ in all files sections. + * Improve copyright file: Refer to FSF website (not postal address), +and put reference below Debian-specific comment to hint that it is +not verbatim copied. Please another time look at possibilities of merging entries when doing git-dch. I would have merged and compacted the multiple changes to copyright file in above. Damn, you're right. Are we hitting a corner case here? With distributed development, the original author probably knows best what's simply cosmetics and what's worth to appear in the changelog. Given that I usually don't remember what I've done a couple of months ago, I tend to add the changelog entries shortly after a period of work, that is, when I think I'm not going to touch the package for the next few weeks. Would it make sense, as a rule of thumb or even a team guideline, to provide changelog entries when done with editing instead of using git-dch just right before the upload? While the latter might work with a single maintainer, I don't see how it could with multiple people touching a package over several months. Anyway, I'll pay more attention next time. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] calf audio plugins packaging branch, master, updated. debian/0.0.18.5-1-13-g1771d8e
On Tue, Aug 24, 2010 at 06:29:18PM +0200, Adrian Knoth wrote: On Tue, Aug 24, 2010 at 06:16:24PM +0200, Jonas Smedegaard wrote: + [ Jonas Smedegaard ] + * Tidy copyright file: Adjust a few stanzas and declare it formatted +according to draft DEP5 rev135. + * Fix add a missed owner to copyright file (no new licenses). + * Drop local CDBS snippets and locally declared DEB_MAINTAINER_MODE: +All part of main CDBS now. + * Refer to FSF website (not postal address) in rules file header. + * Fix ALSA build-dependency auto-resolving (CDBS no longer horribly +executes control.in file as a shell script). + * Improve watch file: Add usage comment; relax pattern to non-digit +versions and non-gzip tarball compression. + * Fix DEP5 synatx of copyright file: append ./ in all files sections. + * Improve copyright file: Refer to FSF website (not postal address), +and put reference below Debian-specific comment to hint that it is +not verbatim copied. Please another time look at possibilities of merging entries when doing git-dch. I would have merged and compacted the multiple changes to copyright file in above. Damn, you're right. Are we hitting a corner case here? With distributed development, the original author probably knows best what's simply cosmetics and what's worth to appear in the changelog. Given that I usually don't remember what I've done a couple of months ago, I tend to add the changelog entries shortly after a period of work, that is, when I think I'm not going to touch the package for the next few weeks. Would it make sense, as a rule of thumb or even a team guideline, to provide changelog entries when done with editing instead of using git-dch just right before the upload? While the latter might work with a single maintainer, I don't see how it could with multiple people touching a package over several months. Anyway, I'll pay more attention next time. I think we are both right: It makes sense *both* to update changelog after finishing a round of work *and* right before release. I obviously got distracted back then: Today when I noticed your (many attempts at) upload, I looked at my local git and found some additional copyright file improvements that I hadn't commit'ed yet. :-) - 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: [SCM] calf audio plugins packaging branch, master, updated. debian/0.0.18.5-1-13-g1771d8e
On Tue, Aug 24, 2010 at 07:04:13PM +0200, Jonas Smedegaard wrote: ...and I should be more lazy and not complain about every single commit. (I didn't comment on your commiting a bumped empty changelog entry) As proposed by our packaging guidelines: After each upload to the Debian FTP servers, the first commit should be creating a new changelog entry, to ease testing of unreleased packages. http://wiki.debian.org/DebianMultimedia/DevelopPackaging -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] multicat packaging branch, master, updated. debian/1.0-1-3-g4c116f9
[sent again, to proper mailinglist this time] On Tue, Aug 24, 2010 at 07:08:32PM +, ivoire-gu...@users.alioth.debian.org wrote: Some patches to add a missing license and fix some typos. diff --git a/debian/gbp.conf b/debian/gbp.conf index 8e96d07..1ee58fc 100644 --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -1,3 +1,4 @@ [git-buildpackage] pristine-tar = True compression = bzip2 +ignore-new = True Above is not a patch. Also, I find it unwise to enable that option - if source is not clean after build + clean then something is wrong which should be fixed instead. - 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: [SCM] multicat packaging branch, master, updated. debian/1.0-1-3-g4c116f9
Le mardi 24 août 2010 à 09:33:56, Jonas Smedegaard a écrit : [sent again, to proper mailinglist this time] On Tue, Aug 24, 2010 at 07:08:32PM +, ivoire-gu...@users.alioth.debian.org wrote: Some patches to add a missing license and fix some typos. diff --git a/debian/gbp.conf b/debian/gbp.conf index 8e96d07..1ee58fc 100644 --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -1,3 +1,4 @@ [git-buildpackage] pristine-tar = True compression = bzip2 +ignore-new = True Above is not a patch. You are right I might have split it in two commits. Also, I find it unwise to enable that option - if source is not clean after build + clean then something is wrong which should be fixed instead. I'm usually doing git-buildpackage, change something, commit it and then git-buildpackage again. The second one complain. It does not complain if I add this option (but I can do a dh_quilt_unpatch before git-buildpackage if this option is not recommended) -- Rémi Duraffort | ivoire http://ivoire.dinauz.org/blog/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] multicat packaging branch, master, updated. debian/1.0-1-3-g4c116f9
On 24/08/10 16:24, Rémi Duraffort wrote: Le mardi 24 août 2010 à 09:33:56, Jonas Smedegaard a écrit : [sent again, to proper mailinglist this time] On Tue, Aug 24, 2010 at 07:08:32PM +, ivoire-gu...@users.alioth.debian.org wrote: Some patches to add a missing license and fix some typos. diff --git a/debian/gbp.conf b/debian/gbp.conf index 8e96d07..1ee58fc 100644 --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -1,3 +1,4 @@ [git-buildpackage] pristine-tar = True compression = bzip2 +ignore-new = True Above is not a patch. You are right I might have split it in two commits. Also, I find it unwise to enable that option - if source is not clean after build + clean then something is wrong which should be fixed instead. I'm usually doing git-buildpackage, change something, commit it and then git-buildpackage again. The second one complain. It does not complain if I add this option (but I can do a dh_quilt_unpatch before git-buildpackage if this option is not recommended) It is not necessary to do git-buildpackage to test a change. Also, to avoid this very problem, I set in my ~/.gbp.conf export-dir=../build-area So it will build in a clean directory, and not touch my working tree. -- 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] multicat packaging branch, master, updated. debian/1.0-1-3-g4c116f9
On Tue, Aug 24, 2010 at 10:24:25PM +0200, Rémi Duraffort wrote: Le mardi 24 août 2010 à 09:33:56, Jonas Smedegaard a écrit : [sent again, to proper mailinglist this time] On Tue, Aug 24, 2010 at 07:08:32PM +, ivoire-gu...@users.alioth.debian.org wrote: Some patches to add a missing license and fix some typos. diff --git a/debian/gbp.conf b/debian/gbp.conf index 8e96d07..1ee58fc 100644 --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -1,3 +1,4 @@ [git-buildpackage] pristine-tar = True compression = bzip2 +ignore-new = True Above is not a patch. You are right I might have split it in two commits. Also, I find it unwise to enable that option - if source is not clean after build + clean then something is wrong which should be fixed instead. I'm usually doing git-buildpackage, change something, commit it and then git-buildpackage again. The second one complain. It does not complain if I add this option (but I can do a dh_quilt_unpatch before git-buildpackage if this option is not recommended) git-buildpackage currently do not work 100% with quilt variant of source format 3.0. What I personally do after clean is this - manually: QUILT_PATCHES=debian/patches quilt pop -a [check that .pc is virtually empty] rm -rf .pc I dislike integrating above with packaging rules, as I consider the issue a bug/limitation in either or both of git-buildpackage and dpkg, so fixing it in packaging really means covering over a bug somewhere else. Others in this team disagree with me. Some git-ignore .pc subdir. Some implement quit-unrolling in clean rule or some other rule. I believe that your above approach (I notice that you since reverted it) is bad even if you find my approach too complex/stupid/whatever: it ignores *any* changes in source, not only the patches. 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
