reply
Hello My Name is Michele Maiya, can you be my soul mate? From, Michele. ___ 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: review jack-keyboard
On Thu, Aug 26, 2010 at 4:00 PM, Arnout Engelen arnou...@bzzt.net wrote: On Thu, Aug 26, 2010 at 03:45:03PM +0200, rosea grammostola wrote: Please review and upload jack-keyboard, a midi keyboard for JACK MIDI http://git.debian.org/git/pkg-multimedia/jack-keyboard.git/ I'm pretty new to this as well, but fixing any lintian errors/warnings is generally a good start: Now running lintian... W: jack-keyboard: copyright-refers-to-deprecated-bsd-license-file solved E: jack-keyboard: copyright-contains-dh_make-todo-boilerplate solved Could someone upload this package please? It's an virtual midi keyboard, similar to Vkeybd but better and it uses JACK MIDI which is more accurate then ALSA MIDI (for software). Thanks in advance, \r ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of a2jmidid_6-1_i386.changes
a2jmidid_6-1_i386.changes uploaded successfully to localhost along with the files: a2jmidid_6-1.dsc a2jmidid_6-1.debian.tar.gz a2jmidid_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
Re: MPEG LA extends fee free use of H.264
On Thu, Aug 26, 2010 at 05:31:45PM +0200, Reinhard Tartler wrote: On Thu, Aug 26, 2010 at 16:27:01 (CEST), Jonas Smedegaard wrote: On Thu, Aug 26, 2010 at 04:00:35PM +0200, Adrian Knoth wrote: Hi! Just a pointer for those who might be concerned: http://www.h-online.com/open/news/item/MPEG-LA-extends-fee-free-use-of-H-264-1067246.html Interesting. I don't know if, e.g. DC10 h264 video files on a server qualify as streaming. Even if it does, it is still only free-from-fee, not free-as-in-speech. So are the IETF RFCs, but we still use their implementations. I think you're missing the point here. Nobody is arguing here about using non-free software, but the ability to watch the debconf videos on mobile phones or iPads, etc., seems very neat to me. PS: we have a dfsg-free implementation of an h264 encoder currently in NEW. I believe the issue raised is if it makes sense for Debian/Debconf to *produce* actively-enforced patent-encumbered material. Yes, I am aware this is patenting, not licensing. Yes, it would be nice if the whole world was free, not only some software on top of some hardware. No, TTBOMK Debian do not *produce* any non-free RFCs even if we ship some in non-free. Yes, nobody is arguing about using non-free software. Not even me :-) - Jonas [1] Debconf and Debian are separate entities, although participants overlap. -- * 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: Hints on packaging a library
On 26/08/10 11:31, Alexandre Quessy wrote: Hello everyone, I was wondering if someone had hints on how to package a library. The things I want to package are often distributed with at least an executable which uses them. The packages I am working and contain libraries on are: scenic, spinframework. I am also interested in packaging lyd. For now, I used CDBS, but I would like to give a try to dh 7, to compare. :) Whatever works first... Any examples of packages I should check out? Liblo is really straightforward, as you noted. The problem with shared libraries is not the packaging per se, but the updating of it to avoid partial upgrades breaking, ABI breaks and other breakage. I looked at liblo, which is a library I know and use. It's pretty straightforward. I found some info about the soversion (liblyd0, for example) in the Debian policy manual. http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-shlibs There is no debian/shlibs file in the Git repo for the packaging of liblo. I guess it's generated by the debian/rules file? No, liblo doesn't have a shlibs file because it has a symbols file. Symbols provide a finer grained dependency check, but at a higher overhead. It seems like the versioning of the shlibs rely on the LO_SO_VERSION=7:0:0 in configure.ac. Some project may not provide this upstream. No, that accounts for the SONAME (the 7.0.0 part after liblo.so). If a project does not provide a SONAME, then please tell upstream to start doing so, or just package it as a private library. -- 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: request for membership, ITA
On Wed, 2010-08-25 at 14:22 +0200, Jonas Smedegaard wrote: Please read http://wiki.debian.org/DebianMultimedia - and especially http://wiki.debian.org/DebianMultimedia/Join :-) When that's done, you have write access to our Git area at Alioth: then please upload your packaging there and let us[1] look at it together. I forgot to mention that my username on alioth is: rdz-guest Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: vlc 1.1.3
Hello, Mehdi Dogguy wrote: I'll unblock it later… vlc/1.1.3-1 has now built on all archs and is 5 days old. Could you unblock it ? Thanks -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Hints on packaging a library
On Thu, Aug 26, 2010 at 11:31:43AM -0400, Alexandre Quessy wrote: I was wondering if someone had hints on how to package a library. The things I want to package are often distributed with at least an executable which uses them. My approach would be to suggest look at some library packages and try understand how each and every bit of information in them works. ...but it seems this is what you are doing already. :-) Feel free to ask about bits and pieces of the packages I am involved in - I do try to have reasoning for every little comma in them, and would be happy to either clarify or be proven wrong (and then correct the bits revealed as being just casual or whatever). The packages I am working and contain libraries on are: scenic, spinframework. I am also interested in packaging lyd. Lyd? What is that? It is the danish (and norwegian) word for sound, but I never heard of it being a code project. For now, I used CDBS, but I would like to give a try to dh 7, to compare. :) Whatever works first... Any examples of packages I should check out? As you might know by now, I only have CDBS examples :-) Feel free to pick and interrogate me about any of the 140+ packages which contains libraries from this list: http://qa.debian.org/developer.php?login...@jones.dk (in worst case you dig up something I haven't polished for some time, but that will be beneficial to the community to then get it straightened up - and perhaps you might learn something in that process too?) I looked at liblo, which is a library I know and use. It's pretty straightforward. Yeah, that one is almost as simple as it can get. The rules file of that one could be much simpler if I wasn't so fond of some modern CDBS surplus, and .install files could be slightly trimmed if (or when) switching to debhelper 7. But apart from that, liblo is probably as it gets. But beware - partly it has to do with the library itself being quite simple: There are not really any build-dependencies, so no development dependencies to keep track of. A more realistic example is liblrdf - using d-shlibs, patching source so needing autotools reconfiguration (with the extra juggling it brings when not taking the easy route of agressive gitignore use). I found some info about the soversion (liblyd0, for example) in the Debian policy manual. http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-shlibs There is no debian/shlibs file in the Git repo for the packaging of liblo. I guess it's generated by the debian/rules file? That manual section describes how an shlibs file must end in the binary package, and that it _may_ end there by putting a similarly named file in the source package which then is installed with a debhelper script. I prefer to resolve information dynamically whenever possible, and use d-shlibs for (most of) the library parts. Might be that I got it wrong (I am certainly no expert in this area) but apparently the community is happy with e.g. uw-imap, libgd2, ghostscript, jbig2dec and other library packages that I maintain - none of which needs a shlibs file in the source package. It seems like the versioning of the shlibs rely on the LO_SO_VERSION=7:0:0 in configure.ac. Some project may not provide this upstream. If upstream do not maintain SONAME properly then you have a coding issue, not just a packaging one. You can patch code during packaging but packaging tools do not solve broken software, so don't look there for magic solutions to broken upstream code. 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: vlc 1.1.3
On 08/27/2010 12:28 AM, Christophe Mutricy wrote: Hello, Mehdi Dogguy wrote: I'll unblock it later… vlc/1.1.3-1 has now built on all archs and is 5 days old. Could you unblock it ? Done. -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ ___ 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 Wed, 2010-08-25 at 14:22 +0200, Jonas Smedegaard wrote: When that's done, you have write access to our Git area at Alioth: then please upload your packaging there and let us[1] look at it together. Thanks for your help. Am I supposed to have already access to git.debian.org/git/pkg-multimedia? I think I don't. My username on alioth is rdz-guest. Thanks Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Hints on packaging a library
On Thu, Aug 26, 2010 at 17:31:43 (CEST), Alexandre Quessy wrote: There is no debian/shlibs file in the Git repo for the packaging of liblo. I guess it's generated by the debian/rules file? yes, see the manpage of dh_makeshlibs. The file is generally created during runtime of debian/rules, but policy does not require that dynamics. It seems like the versioning of the shlibs rely on the LO_SO_VERSION=7:0:0 in configure.ac. Some project may not provide this upstream. This is a libtool speciality and not every upstream uses libtool. Many other upstreams prefer to add the -soname parameter to the linker themselves in order to avoid libtool's complexity. -- 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: request for membership, ITA
Hi Romain On Wed, 2010-08-25 at 10:32 -0500, Romain Beauxis wrote: I have always wanted to look at PD more closely I think it is definitely worth it. I'll be glad to help, if you need it. and I also packaged cwiid, which I suspect is a dependency of this package. Indeed, it is. Therefore, it seems I am a good candidate to look at this :-) So I am very glad that I met you ;-) I will try to do it soon, ping me if no one else did it before and I did not send any follow-up.. No hurry. For my part, I am very happy to join the team and to collaborate, but forgive me if I sometimes answer mails not immediately (as my free time is sometimes a bit fragmented) Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
On Thu, Aug 26, 2010, Reinhard Tartler wrote: For the base flavor, I totally agree. For the specialized neon flavor, I'm not sure if that's so important. But I have to admit that I'm really not an expert for armel, so I fully trust your judgement here. Actually my test logic was wrong; I realized when implementing the v7 part I mentioned: if v7 isn't enabled by default, then the NEON pass should enable it since NEON implies v7. v6t2 was a distraction, I removed it. I committed this to ffmpeg git, but I didn't understand the way the changelog was maintained (apparently you create an entry after the last upload?). Mind fixing it up? Thanks! -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#590706: Debug informations
Debug informations with gdb attached, hope this helps. gdb projectM-jack GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/projectM-jack...Reading symbols from /usr/lib/debug/usr/bin/projectM-jack...done. (no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/projectM-jack [Thread debugging using libthread_db enabled] dir:/usr/share/projectM/config.inp reading ~/.projectM/config.inp [New Thread 0xb54f7b70 (LWP 7937)] [New Thread 0xb0b3ab70 (LWP 7938)] [New Thread 0xb0339b70 (LWP 7939)] [New Thread 0xafb38b70 (LWP 7940)] [projectM] config file: /home/fab/.projectM/config.inp No Textures Loaded from /usr/share/projectM/textures Program received signal SIGSEGV, Segmentation fault. 0xb6ddec37 in FTSize::CharSize(FT_FaceRec_**, unsigned int, unsigned int, unsigned int) () from /usr/lib/libftgl.so.2 (gdb) bt #0 0xb6ddec37 in FTSize::CharSize(FT_FaceRec_**, unsigned int, unsigned int, unsigned int) () from /usr/lib/libftgl.so.2 #1 0xb6ddd7a1 in FTFace::Size(unsigned int, unsigned int) () from /usr/lib/libftgl.so.2 #2 0xb6de5dda in FTFontImpl::FaceSize(unsigned int, unsigned int) () from /usr/lib/libftgl.so.2 #3 0xb6de5002 in FTFont::FaceSize(unsigned int, unsigned int) () from /usr/lib/libftgl.so.2 #4 0xb7f0c25b in Renderer (this=0x89f54e0, width=512, height=512, gx=32, gy=24, texsize=1024, beatDetect=0x8a046d0, _presetURL=..., _titlefontURL=..., _menufontURL=...) at /build/rt-projectm_2.0.1+dfsg-3-i386-TokLKs/projectm-2.0.1+dfsg/src/libprojectM/Renderer/Renderer.cpp:59 #5 0xb7ec8bdf in projectM::projectM_init (this=0x89f4318, gx=32, gy=24, fps=35, texsize=1024, width=512, height=512) at /build/rt-projectm_2.0.1+dfsg-3-i386-TokLKs/projectm-2.0.1+dfsg/src/libprojectM/projectM.cpp:488 #6 0xb7ec985a in projectM::readConfig (this=0x89f4318, configFile=...) at /build/rt-projectm_2.0.1+dfsg-3-i386-TokLKs/projectm-2.0.1+dfsg/src/libprojectM/projectM.cpp:223 #7 0xb7ec9fbb in projectM (this=0x89f4318, config_file=..., flags=1) at /build/rt-projectm_2.0.1+dfsg-3-i386-TokLKs/projectm-2.0.1+dfsg/src/libprojectM/projectM.cpp:121 ---Type return to continue, or q return to quit--- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#594093: NEON pass failure on ffmpeg
On Fri, Aug 27, 2010 at 01:42:17 (CEST), Loïc Minier wrote: On Thu, Aug 26, 2010, Reinhard Tartler wrote: For the base flavor, I totally agree. For the specialized neon flavor, I'm not sure if that's so important. But I have to admit that I'm really not an expert for armel, so I fully trust your judgement here. Actually my test logic was wrong; I realized when implementing the v7 part I mentioned: if v7 isn't enabled by default, then the NEON pass should enable it since NEON implies v7. v6t2 was a distraction, I removed it. thanks! I committed this to ffmpeg git, but I didn't understand the way the changelog was maintained (apparently you create an entry after the last upload?). Mind fixing it up? I've just fixed it up. the general idea is to start an upload with an 'dummy' debian/changelog entry indicating the next version, and finalize it using git-dch(1) just before the upload. -- 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
vlc 1.1.3-1 MIGRATED to testing
FYI: The status of the vlc source package in Debian's testing distribution has changed. Previous version: 1.1.2-1 Current version: 1.1.3-1 -- 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
[bts-link] source package jackeq
# # bts-link upstream status pull for source package jackeq # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #583923 (http://bugs.debian.org/583923) # * http://sourceforge.net/tracker/?func=detailaid=3049384 # * remote status changed: (?) - Open usertags 583923 + status-Open thanks ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
[bts-link] source package src:qjackctl
# # bts-link upstream status pull for source package src:qjackctl # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #556304 (http://bugs.debian.org/556304) # * http://sourceforge.net/tracker/?func=detailaid=3050915 # * remote status changed: (?) - Pending usertags 556304 + status-Pending thanks ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
[bts-link] source package qjackctl
# # bts-link upstream status pull for source package qjackctl # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #293454 (http://bugs.debian.org/293454) # * http://sourceforge.net/tracker/?func=detailaid=3050750 # * remote status changed: (?) - Open usertags 293454 + status-Open # remote status report for #581440 (http://bugs.debian.org/581440) # * http://sourceforge.net/tracker/?func=detailaid=3050745 # * remote status changed: (?) - Open usertags 581440 + status-Open # remote status report for #581874 (http://bugs.debian.org/581874) # * http://sourceforge.net/tracker/?func=detailaid=3050752 # * remote status changed: (?) - Open usertags 581874 + status-Open # remote status report for #593877 (http://bugs.debian.org/593877) # * http://sourceforge.net/tracker/?func=detailaid=3050744 # * remote status changed: (?) - Open usertags 593877 + status-Open thanks ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction
Did you have a look at my packages? -- gpg-id: B4F786B1 signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#594636: general: vlc_1.1.2.orig.tar.bz2. FAIL to make the .deb packages (source and binary)
Processing commands for cont...@bugs.debian.org: reassign 594636 vlc Bug #594636 [general] general: vlc_1.1.2.orig.tar.bz2. FAIL to make the .deb packages (source and binary) Bug reassigned from package 'general' to 'vlc'. kthxbye Stopping processing here. Please contact me if you need assistance. -- 594636: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594636 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#594636: general: vlc_1.1.2.orig.tar.bz2. FAIL to make the .deb packages (source and binary)
reassign 594636 vlc kthxbye -- Jonathan Wiltshire 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#591881: vlc-nox: package fails to upgrade properly from lenny
On Thu, Aug 26, 2010 at 17:29:43 (CEST), David Kalnischkies wrote: 2010/8/26 Reinhard Tartler siret...@tauware.de: I'm still waiting for an answer on this question. Is this issue solved with the latest upload, or do you prefer me to upload the patch posted above? It would be nice if you could fix it in your package (which at least feels a bit cleaner anyway: liba2 breaks liba1 sounds saner than libpartlyunrelated breaks liba1). After preparing an upload for this, I've tried to reproduce this issue myself in a virtual machine. The thing is, I've not been able to reproduce this neither with lenny's apt, nor squeeze's apt (0.7.25.3) nor sid's (0.8.0) apt. What I've did was: - do a basic lenny installation - apt-get install install ffmpeg - sed -i s,lenny,sid,g /etc/apt/sources.list - apt-get update -qq - apt-get install ffmpeg AFAIUI the bugreport, this should trigger this bug, however, I fail to reproduce it. I've also tried with vlc and vlc-nox, but this worked just fine as well. Lucas, could you please assist me here how to reproduce this bug? -- 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: pd-zexy compilation improvements
On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote: 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? 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 It seems it's not dh_strip who does the stripping. In the case of the gem package it seems to happen already at compile time. After putting an unstripped Gem.pd_linux in the temporary directory running dh_strip won't touch it all. Also it seems as if dh_shlibdeps looks only for .so-files. I haven't figured out what trickery was used in the gem package to let it find also .pd_linux-files. But having a plain .pd-linux file in the temporary directory and running dh_shlibdeps doesn't produce anything useful. Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: gmerlin-avdecoder redux
On Mon, Aug 16, 2010 at 09:12:32PM +0200, IOhannes m zmoelnig wrote: On 2010-08-12 19:33, Hans-Christoph Steiner wrote: Do you think you could do the upstream-tarball.mk thing to the gmerlin-avdecoder package? The folders in question are: lib/libwin32dll lib/GSM610 regarding the lib/GSM610 folder, on the gmerlin list people don't see why it shouldn't be compatible with GPL: Agreed. I must confess that I blindly stripped without verifying - at the time I thought that my action was to demonstrate _how_ to elegantly strip from source, and then let Hans-Christoph document _why_. ...but I never communicated that :-( The GSM code is the same as already shipped as a shared library in libgsm1, so indeed it is safe to include with source, but we should not use it but instead link against that shared library. 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: pd-zexy compilation improvements
On Fri, Aug 27, 2010 at 12:11:16PM +0200, IOhannes zmölnig wrote: 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) Thanks for the long explanation. I am thrilled to be around such knowledgeable folks here! - 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: request for membership, ITA
On 26/08/10 14:39, Roman Haefeli wrote: On Wed, 2010-08-25 at 14:22 +0200, Jonas Smedegaard wrote: When that's done, you have write access to our Git area at Alioth: then please upload your packaging there and let us[1] look at it together. Thanks for your help. Am I supposed to have already access to git.debian.org/git/pkg-multimedia? I think I don't. My username on alioth is rdz-guest. Now you do. Welcome to the team! -- 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: pd-zexy compilation improvements
On 27/08/10 18:18, Roman Haefeli wrote: On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote: 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? 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 It seems it's not dh_strip who does the stripping. In the case of the gem package it seems to happen already at compile time. After putting an unstripped Gem.pd_linux in the temporary directory running dh_strip won't touch it all. dh_strip doesn't strip anything it doesn't recognize (and it has no way of being forced into it). Add comments to bug #468333 to ask for support for this. In the meantime, you can call strip --remove-section=.comment --remove-section=.note --strip-unneeded on each of the pd_linux files. Also it seems as if dh_shlibdeps looks only for .so-files. I haven't figured out what trickery was used in the gem package to let it find also .pd_linux-files. But having a plain .pd-linux file in the temporary directory and running dh_shlibdeps doesn't produce anything useful. You can pass additional arguments for dh_shlibdeps to process: dh_shlibdeps -- $file1 $file2 -- 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: request for membership, ITA
Hello! 2010/8/27 Felipe Sateler fsate...@debian.org: On 26/08/10 14:39, Roman Haefeli wrote: I think I don't. My username on alioth is rdz-guest. Now you do. Welcome to the team! This is good news, Roman! Keep the good work! -- Alexandre Quessy http://alexandre.quessy.net/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
