Re: pd-zexy: broken Build-Depends
On 01/17/2013 10:28 AM, Thorsten Glaser wrote: Hi, pd-zexy has alternative Build-Depends, however, they don’t work: […] pbuilder-satisfydepends-dummy : Depends: puredata-core which is a virtual package. or puredata ( 0.43) but it is not going to be installed. hmm, any idea why puredata-core is named a virtual package? it is as real as a package can get. The following actions will resolve these dependencies: Install the following packages: […] 8) puredata [0.41.4-1 (unstable)] […] checking pd/m_pd.h usability... no checking pd/m_pd.h presence... no checking for pd/m_pd.h... no configure: error: m_pd.h is desperately needed! install pd and/or use --with-pd=/path/to/pd/ make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 ouch; you discovered an upstream bug. i'll forward it, and could provide a patch that fixes the problem. I think dropping the alternative on puredata is way to go. I’ll just build its newer version, but due to the existence of the alternative B-D, wanna-build considers pd-zexy to be eligible for building. ah btw, the B-D in question is really puredata-dev | puredata ( 0.43) rather than puredata-core | puredata ( 0.43) the latter is merely for runningthe test-suite. gfmdsr IOhannes ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy: broken Build-Depends
On 01/17/2013 07:33 PM, Thorsten Glaser wrote: Felipe Sateler dixit: (CCing you because I don't know if you are suscribed) I’m not, thanks. Well, your puredata is from before stable... With the current build depends pd-zexy can be built in stable. as a matter of fact, i'm not entirely sure about this. sdft IOhannes ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy: broken Build-Depends
On 01/17/2013 01:43 PM, Felipe Sateler wrote: At some point (the changelog doesn't say) before squeeze the header was moved from /u/include/m_pd.h to /u/i/pd/m_pd.h, which is where for the record: the old header location is still available (symlinked) modern packages expect it, which is why your build is failing. configure is supposed to check both the new and the old header, but unfortunately stops checking after the check for the new header location failed (due to the upstream bug i mentioned). gsdmrt IOhannes ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: updated packages: pd-iemnet pd-osc
On 06/28/2012 11:28 PM, Felipe Sateler wrote: I am uploading. thanks Commit 192da32 serves 2 purposes: convert to final dep-5 format and merge explicit entries into a single generic one. Next time, please split the commits accordingly. i agree, sorry. fgmarsd IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
RC Bug #679318 (was Re: Bug#679318: flumotion: twisted override bug - one more)
tag 679318 +pending thanks On 06/27/2012 10:32 PM, John Bazik wrote: Package: flumotion Version: 0.10.0-2 Severity: grave Tags: upstream patch Justification: renders package unusable This is the same problem I reported in #672404, but affecting a different part of the code (there are two places that need to be fixed). To recap, flumotion overrides an internal method in twisted, which has changed. thanks for the patch again. i updated the flumotion package accordingly and pushed the changes to git. i also updated debian/changelog accordingly (and set the target to release) in order to speed things up. (hopefully jonas will forgive me for this) if anyone could upload this fix for an RC-bug, that would be great. fgamsr IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: updated packages: pd-iemnet pd-osc
On 06/25/2012 10:09 PM, IOhannes m zmoelnig wrote: On 2012-06-25 02:58, Felipe Sateler wrote: On Thu, Jun 14, 2012 at 2:25 PM, IOhannes m zmoelnig zmoel...@iem.at wrote: pd-iemnet: - pushed standards - fixed build-depends and depends - updated debian/changelog to the final DEP-5 format - enabled hardening builds I don't quite like this patch. It looks like it should be just a one-line patch but some editor preference managed to turn it into a 80-line thing. Can you please fix this? oops, sorry. it indeed should be a two-line patch. fixed and pushed. ping. before it's too late. fgdmr IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: please upload: pd-zexy 2.2.5
On 11/11/2011 03:02 AM, Felipe Sateler wrote: On Thu, Nov 10, 2011 at 13:31, IOhannes m zmoelnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i hopefully fixed the remaining issues with pd-zexy (namely: depending on puredata-core rather than puredata; not shipping license files that are in debian anyhow) the new package fixes an RC bug, so i think it rather important to have it included asap. also, the last package was uploaded by felipe on 2010-11-09, so i thought it a nice coincidence to update it just after a year :-) Off-by-one... true, but i thought i'll take the chance :-) but I couldn't upload :(. THe build dependency should be puredata-dev | puredata ( 0.43), since puredata = 0.43 is not enough to build. hmm, puredata _should_ be enough even with 0.43, as it depends on puredata-dev. there was a bug in the puredata (=0.43 0.43.0-4) package, where puredata would not depend on puredata-dev. this has been fixed with 0.43.0-4, which afaik is the only 0.43 package to be found in debian (=wheezy) and ubuntu (=oneric). am i missing something? fgmasr IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
gmerlin-avdecoder ready (2nd try)
i think i fixed the remaining issues with gmerlin-avdecoder. package appears to be lintian clean. gmasr IOhannes 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
Re: libgmerlin0 - libgmerlin1
On 01/14/2011 07:16 PM, IOhannes zmölnig wrote: it seems like gmerlin-1.0.0 provides a libgmerlin that is binary incompatible with the gmerlin-0.4.3 release. namely, some symbols have been dropped. hmm, after closer inspection ofthe output of dpkg-gensymbols, it seems like this was a false alarm. the libgmerlin0.symbols files contains a number of MISSING stanzas, which seem to have been merely updated: -#MISSING: 0.4.3# (optional)pixbuf_destroy_notify@Base 0.4.1 +#MISSING: 1.0.0~dfsg-1# (optional)pixbuf_destroy_notify@Base 0.4.1 it seems like all MISSING stanzas for 1.0.0 have also been there for 0.4.3 the rest of the changes are only additions. so i guess we are still save. but then: how come that there are MISSING stanzas at all? does this indicate, that at some point in the past, the library API did change, and it was ignored? as i understand it, this means that the SONAME has to change. unfortunately i don't have any real clue what this means in practice. i guess, a start would be to simply rename the binary package to libgmerlin1 ah, i found the libpkg-guide. and that the soname should change in the build-process (automake) fbmas IOhannes 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
libgmerlin0 - libgmerlin1
it seems like gmerlin-1.0.0 provides a libgmerlin that is binary incompatible with the gmerlin-0.4.3 release. namely, some symbols have been dropped. as i understand it, this means that the SONAME has to change. unfortunately i don't have any real clue what this means in practice. i guess, a start would be to simply rename the binary package to libgmerlin1 anything else? fgmasdr IOhannes 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
Re: Bug#605827: pd-iemnet: FTBFS on non-Linux: undefined references
On 12/08/2010 06:06 AM, Hans-Christoph Steiner wrote: On Tue, 2010-12-07 at 10:00 -0300, Felipe Sateler wrote: On Mon, Dec 6, 2010 at 14:23, IOhannes m zmoelnig zmoel...@iem.at wrote: On 2010-12-03 21:26, Cyril Brulebois wrote: Source: pd-iemnet Version: 0.1-1 Severity: important Hi, your package FTBFS on non-Linux with undefined references: thanks for reporting. this hould be fixed in the next upload. @pkg-multimedia-maintainers: i have updated the git repository to include the makefile fixes for both hurd and kFreeBSD. Are these fixes only on the Makefile template? (Sorry I'm not on my pc right now). If so, this patch should be applied to all the pd-* packages we have. My most recent packages included an attempt to fix these build issues. Once those prove successful, I'll update the rest of my packages. i tested the fix on kFreeBSD (though not on hurd), and it works. i find it faster and more convenient to setup an emulation (VirtualBox, qemu,...) running kFreeBSD/i386 and hurd/i386 and test changes there than to wait for a DD to upload a package that has a potential fix for a problem, then wait until the package is accepted into unstable (we are talking about NEW packages here), esp. as long as squeeze is still frozen, then wait till it gets build on the relevant architecture (i remember Gem being stalled for about 2 months because of a dead armel machine), then study the build logs and re-iterate till the problem gets really fixed. fgmasdr IOhannes 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
pd-pkg-tools
hi all, based on previous suggestion i started to create a (debian native) package pd-pkg-tools, which should make packaging of pd-libraries easier. currently it only contains new snippets for cdbs, but on the long run i'd like to have dh-shortform makefile snippets as well. the package itself uses CDBS. i haven't filed an ITP yet (is there any difference between a debian/native package and a normal upstream package, regarding debian policy?...probably i should just have a look at the dp :-)) also i don't know whether this is a welcome addition to pkg-multimedia. therefore, for the time being, i have only pushed the package to my repository at github: https://github.com/umlaeute/pd-pkg-tools so if somebody could have a look i would be grateful. esp, my cdbs knowledge is probably not very sophisticated (yet), so i might have done all the DONTs (e.g. i still have no real clue what is supposed to go into class and what should go into rules) so far i have packaged one very simple pd-library with it, and the debian/rules file boils down to 3 lines (without the boiler-plate). this package (pd-syslog) is currently also on github https://github.com/umlaeute/pd-syslog since i was unsure about it's hard dependency on pd-pkg-tools. comments please fgmasdr IOhannes 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
Re: pd-pkg-tools
On 12/03/2010 02:42 PM, Felipe Sateler wrote: 2010/12/3 IOhannes zmölnig zmoel...@iem.at: hi all, based on previous suggestion i started to create a (debian native) package pd-pkg-tools, which should make packaging of pd-libraries easier. Great! cool I would welcome it. cool might have done all the DONTs (e.g. i still have no real clue what is supposed to go into class and what should go into rules) I think this should go into rules, but Jonas can give a more informed answer. i was hoping for jonas to say something on this :-) so far i have packaged one very simple pd-library with it, and the debian/rules file boils down to 3 lines (without the boiler-plate). this package (pd-syslog) is currently also on github https://github.com/umlaeute/pd-syslog since i was unsure about it's hard dependency on pd-pkg-tools. comments please The documentation is a bit wrong: The pd Depends is not handled yet. is it not?... Maybe the Depends should be expanded to a new substvar? that was my original idea. then i discovered that cdbs can already do it, and so i just hooked to that: cdbs:Depends should get updated to depend on pd (if you included .../pd.mk) or puredata (if you included .../puredata.mk) at least this seems to work with the pd-syslog example. however, i'm quite open to go back to pd:Depends as well... Wild wishlist... would it be possible to detect if the installed pd patches/objects use another library? So that the appropriate depends are added? oh, you mean not binary dependencies (as are generated by dpkg-shlibdeps), but simply if an object.pd references [pddp/link] it would automatically depend on pd-pddp? that would be a cool feature indeed, though not easily done. mdfasr IOhannes 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
Re: pd-pkg-tools
On 12/03/2010 03:23 PM, Jonas Smedegaard wrote: It seems to contain *only* hooks for CDBS and (in the future) debhelper), no other PD-specific ressource. I therefore suggest to try well, this could change at any time :-) convince the maintainers of CDBS and debhelper, respectively, to adopt in in their packages, rather than maintaining this special-purpose package. well, i thought it would probably be of minor interest to the entirety of DDs using cdbs to have pd-specific parts in it (it's not that i expect a use as wide as with perl or python). so i picked one of the precedents (namely ruby-pkg-tools) and modelled my package after that. With my CDBS maintainer hat on, I'd be happy to adopt the CDBS parts into CDBS itself! this of course would make long term maintainance easier... fgamsdr IOhannes 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
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On 11/11/2010 08:30 PM, Hans-Christoph Steiner wrote: I'd like to have my packages work on all Debian platforms, but I have never worked with hurd or kfreebsd, nor have had any feedback that there are problems. As far as I can tell, my packages build on all Debian platforms. just call the build-logs for any of those packages. e.g. https://buildd.debian.org/status/package.php?p=pd-motex but this was just meant as an example for the added benefit of using a common cdbs/dh/.. snippet. fgmarsd IOhannes 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
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On 11/12/2010 06:10 PM, Hans-Christoph Steiner wrote: Ah yes, still learning my way around all the Debian tools, they are pretty large. A common snippet would be great, no argument here. so now, we only have to do it :-) About the HURD/kFreeBSD issue, it seems to be a linking issue, do we have to handle the linking differently with those kernels? I guess the Makefile is lacking uname detection for those kernels, since its looking for 'Linux'. Hopefully just using the same settings for the other two kernels will work. yes, i think the only problem is that the Makefile thinks that it is compiling for an unknown target os (because uname returns something unknown), thus no CFLAGS, LDFLAGS,... are defined which means the defaults: the .c files are compiled as applications, which obviously won't work at all. and yes, you should be able to use the very same flags as on linux (and see the other thread why it might be a good idea to keep pd_linux as the filename extension for all debian) fgmasr IOhannes 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
Re: pd-zexy compilation improvements
On 08/24/2010 12:55 PM, Jonas Smedegaard wrote: On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote: 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. i think there is no issue here at all. we are talking about modules (binaries that can be dlopen()ed). dlopen()ed modules are technically quite the same as shlibs (meaning, the way they are built), but are used in a different way, that makes issues such as installation path and/or rpath irrelevant (at least, as far as i understand it) so from this perspective, we don't have to care about the extension. (i guess this came from my confusing use of shared library; sorry for that; anyhow, debian-policy is quite clear that modules need not have an .so extension) the other point is of course, whether tools like dh_shlibdeps and dh_strip work correctly. i can only say from experience, that they do. e.g. the binary Gem.pd_linux in the package gem is correctly stripped and the package depends on all packages that provide libraries the binary has been dynamically linked to. debian/rules does not extra care of shlibs. so it seems to just work i think that changing the default extension of pd-plugins only in Debian, will make things unnecessary complicated, as it would require to patch the module-loader of puredata as well as practically every single build system for externals, only to find ourselves deviant from and incompatible with virtually any other puredata distribution. to sum up, i don't think the gain would outweigh the cost. (esp. since there is currently no real gain, as adhere to the debian-policy and all tools work as expected) fmgdft IOhannes 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
pd-zexy_2.2.3-2 (please)
i think the current git for pd-zexy includes 2 fixes that would justify a new upload: - fixes kFreeBSD / hurd issue (build-system guessing the wrong module.extension) - fixes policy-violation (sse-binaries on x86) if you agree it would be great if you could review, tag and upload the package (if you have the right permissions) fgmasdr IOhannes 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
Re: request for membership, ITA
On 08/13/2010 02:37 AM, Felipe Sateler wrote: ping. thanks for reviewing Also, the copyright file could use some updating (what are your contributions, etc). There are some files with copyrights other than yourself. thanks. there are some contributions in some files, which i have plainly forgotten. i have updated the debian/copyright notice. debian/dirs seems to be redundant. right; i have deleted it now. it always feels like playing safe when adding directories to debian/dirs... Aand... short-form dh7 seems to not work correctly. since there is a build directory, debian/rules build says that 'build' is up to date. And phony targets do not seem to work with dh7. This means that the package ends up being built under root (in the binary stage), which is frowned upon by policy. i'm not sure whether i fully understand this (i understand the part about the policy; i don't understand the part about dh7): is this a bug i can/should do something about or is it a bug in dh which has to be fixed in the debhelper-package? Why do you install zexy into a non standard pd path? i don't. i install the zexy library (binaries and abstractions) into /usr/lib/pd/extra/zexy/ which is quite the standard way to do it. Pd will look for binaries as /usr/lib/pd/extra/name.pd_linux and as /usr/lib/pd/extra/name/name.pd_linux, so it will be able to load zexy without any further ado. however, zexy bundles a number of abstractions (Pd interpreter files). they used to be installed in Pd's default search path (/usr/lib/pd/extra) and are now installed into /usr/lib/pd/extra/zexy (both upstream and in my debian package) reasoning: - these files are mostly Pd implementations of functionality offered by the binary library. so they are a bit redundant but can be used as drop-in replacement, either for educational purposes or because the user does not want to load the binary plugin - the remaining files are just ordinary Pd files. the user will have to add -path /usr/lib/pd/extra/zexy to their flags in order to use them as they used to do with older version of zexy (e.g. the last debian package). this is mainly to avoid namespace pollution. figuring that in the near future a lot of new packages for Pd will make it into Debian, we have to take care that these packages don't conflict (providing the same files with different functionality). hopefully this can be handled without excessive use of the Conflicts: tag... does this make sense? fgmadrs IOhannes 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
pd-zexy (was Re: request for membership, ITA)
On 08/13/2010 10:13 AM, IOhannes zmölnig wrote: Aand... short-form dh7 seems to not work correctly. since there is a build directory, debian/rules build says that 'build' is up to date. And phony targets do not seem to work with dh7. This means that the package ends up being built under root (in the binary stage), which is frowned upon by policy. i'm not sure whether i fully understand this (i understand the part about the policy; i don't understand the part about dh7): is this a bug i can/should do something about or is it a bug in dh which has to be fixed in the debhelper-package? so i have now switched from using dh directly to cdbs, assuming that this fixes the issue and to get cdbs addicts back on board :-) mfgasdr IOhannes 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
Re: pd-zexy (was Re: request for membership, ITA)
On 08/13/2010 12:05 PM, Jonas Smedegaard wrote: so i have now switched from using dh directly to cdbs, assuming that this fixes the issue and to get cdbs addicts back on board :-) Awesome (for me). For fairness sake, I should probably mention that I am the only one in this team strongly pro CDBS, while it seems (though we have no hard numbers) that several others are opposed to it... i see. the first reaction on #debian-multimedia was: *sigh* more cdbs... README.Debian is wrongly encoded: Your name contain a non-ASCII character not encoded as UTF-8 which is mandatory these days. i'll try to fix that. i never completely figured how to do the UTF-8 think correctly... iconv should do the trickdone! Changelog says the package is quilt'ified. That seems a superfluous comment to me, since there is nothing in the package (not even infrastructure files) for patching. well yes: i started from the original pd-zexy package, which had patches and quiltified them. when upgrading to the latest upstream release, these patches became superfluous (since they were already included). however, source/format now reads 3.0 (quilt), so i thought that was quiltification enough. feel free to remove the line in the changelog. It seems it could make sense to add a NEWS file mentioning the change of path, so that existing users get informed about the need to add to pd-path. that's a good idea. i'll do that. are there any tools for handling the NEWS file? Now that you use CDBS, would you then mind me adding a couple of additional features of that - like auto-resolving build-dependencies, get-orig-source rule and copyright and licensing tracking? sure, go ahead! fgmadr IOhannes 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
