Zwycięzca
Firma Microsoft wybrany za 900.000 dolarów w programie światowej majątek. Uzyskania kwota ta spadnie nazwę i numer lokalny adres ___ 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: Select provider of libav* libraries
Thanks for bringing this up. I vote libav. Cheers. sent via mobile ___ 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: Select provider of libav* libraries
Hi Team! On 2014-08-27 at 00:36 (CEST), Benjamin Drung wrote: [...] So I am asking you: Should we ship libav or FFmpeg? Can we reach a consensus on this topic? Libav for me, of course. I've spent too much time on getting it working fine with Blender that it'd be crazy to change it now. ;-) Cheers. -- Matteo F. Vescovi | Debian Maintainer GnuPG KeyID: 4096R/0x8062398983B2CF7A ___ 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: Select provider of libav* libraries
Hi, 2014-08-27 9:52 GMT+02:00 Matteo F. Vescovi mfvesc...@gmail.com: Hi Team! On 2014-08-27 at 00:36 (CEST), Benjamin Drung wrote: [...] So I am asking you: Should we ship libav or FFmpeg? Can we reach a consensus on this topic? Libav for me, of course. I've spent too much time on getting it working fine with Blender that it'd be crazy to change it now. ;-) If the definition of being crazy is something close to being irrational then making decisions based only on sunken costs can hardly be shown to be the opposite. :-) OTOH it is very human. :-) Cheers, Balint ___ 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: Select provider of libav* libraries
Hi! On 2014-08-27 at 10:54 (CEST), Bálint Réczey wrote: If the definition of being crazy is something close to being irrational then making decisions based only on sunken costs can hardly be shown to be the opposite. :-) OTOH it is very human. :-) Don't get me wrong: it's clear that if the effort would bring to something relevant, I'd be the first to say hey, ok... let's do it now! but, at the present time, I don't see any relevant benefit from the switch, at least on my side (that is limited to a couple of packages, by the way). AFAICT, Blender upstream was (and probably is still) a big fan of FFmpeg library, been that used as default in their code. But they were also proficient in getting Libav working good and smooth in latest upstream releases. So, probably there won't be any evident difference between those two libraries in packaging. I could do some test buildings against FFmpeg once it hits the experimental suite (or whatever). But, as a human being with a real-world-life, I'd prefer spending my spare time with my son than fixing FTBFS on Blender due to FFmpeg ;-P Cheers. -- Matteo F. Vescovi | Debian Maintainer GnuPG KeyID: 4096R/0x8062398983B2CF7A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of mpv_0.5.1-1_amd64.changes
mpv_0.5.1-1_amd64.changes uploaded successfully to ftp-master.debian.org along with the files: mpv_0.5.1-1_amd64.deb mpv-dbg_0.5.1-1_amd64.deb libmpv1_0.5.1-1_amd64.deb libmpv-dev_0.5.1-1_amd64.deb libmpv-dbg_0.5.1-1_amd64.deb mpv_0.5.1-1.dsc mpv_0.5.1.orig.tar.gz mpv_0.5.1-1.debian.tar.xz Greetings, Your Debian queue daemon (running on host coccia.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of mpv_0.5.1-1_amd64.changes
mpv_0.5.1-1_amd64.changes uploaded successfully to localhost along with the files: mpv_0.5.1-1_amd64.deb mpv-dbg_0.5.1-1_amd64.deb libmpv1_0.5.1-1_amd64.deb libmpv-dev_0.5.1-1_amd64.deb libmpv-dbg_0.5.1-1_amd64.deb mpv_0.5.1-1.dsc mpv_0.5.1.orig.tar.gz mpv_0.5.1-1.debian.tar.xz 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
mpv_0.5.1-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 27 Aug 2014 11:05:35 +0200 Source: mpv Binary: mpv mpv-dbg libmpv1 libmpv-dev libmpv-dbg Architecture: source amd64 Version: 0.5.1-1 Distribution: unstable Urgency: medium Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Changed-By: Alessandro Ghedini gh...@debian.org Description: libmpv-dbg - video player based on MPlayer/mplayer2 (client library debug) libmpv-dev - video player based on MPlayer/mplayer2 (client library dev files) libmpv1- video player based on MPlayer/mplayer2 (client library) mpv- video player based on MPlayer/mplayer2 mpv-dbg- video player based on MPlayer/mplayer2 (debug) Changes: mpv (0.5.1-1) unstable; urgency=medium . * New upstream release Checksums-Sha1: 23fcb26dab40f2347da013412af31f2fc85c 2827 mpv_0.5.1-1.dsc 7501f349e0eaf4c1b148e0c18eaaa10954e35701 2578385 mpv_0.5.1.orig.tar.gz 7150f3ab81584c37d593cdec00826a01638200f7 91860 mpv_0.5.1-1.debian.tar.xz aa1ed92ac2c198e3e18236aab7b5aaea4a3174ac 735466 mpv_0.5.1-1_amd64.deb 2c3205bc81cb11650757a9492a04eb24f4532c99 1904776 mpv-dbg_0.5.1-1_amd64.deb 54e433290d89c0632e324567e19affc7232de649 575586 libmpv1_0.5.1-1_amd64.deb ffd799adb5007a1cd31061ad75e87c2c6cf59bea 25742 libmpv-dev_0.5.1-1_amd64.deb 5c6b025dd2e0f40118dfbbef80f28f9b449ed434 1891466 libmpv-dbg_0.5.1-1_amd64.deb Checksums-Sha256: 99e9c68bd2bad2d9136bee964d3519019696183e4acc1136d8cdb4190454058e 2827 mpv_0.5.1-1.dsc 7a16d71cb2921dc1de74bc309d4f7e53dbe75dd6637f3e763e4983d14602a7ec 2578385 mpv_0.5.1.orig.tar.gz 44c29bc84d92862b02d3869eea8f5a1c4285d4a0d96fce0cdd6a897bfc4b3602 91860 mpv_0.5.1-1.debian.tar.xz 3248a171bab1bc50362336224ca2f8a076d1bc3b0e1a674ffd78156ac5e34b03 735466 mpv_0.5.1-1_amd64.deb 299e2ce2394665f9d7a27bd9df1c93abafca3ca87bfee5733d30041f66c71ca1 1904776 mpv-dbg_0.5.1-1_amd64.deb 7dd2175bf2c304e89210f621fd40068df8a0112879554540fd85865336434067 575586 libmpv1_0.5.1-1_amd64.deb 06bc4399a4faea798a36387612e171937b160b17d341dc99fa317d04fc01b5ea 25742 libmpv-dev_0.5.1-1_amd64.deb 86fd63376687fc4a1dc14fe353f30321aebb15214e255097bc2f23525a12d752 1891466 libmpv-dbg_0.5.1-1_amd64.deb Files: 8b05e233e3f7045052b90f9090c71d7c 735466 video optional mpv_0.5.1-1_amd64.deb 67ca9d607c4009ce11dde2094e3a2af6 1904776 debug extra mpv-dbg_0.5.1-1_amd64.deb a670778f91e37d4d1793d870109d120f 575586 libs optional libmpv1_0.5.1-1_amd64.deb ffdad6208a93d443f7ae57871604b514 25742 libdevel optional libmpv-dev_0.5.1-1_amd64.deb b1b863a7b83505e4b5f6b9d60f352776 1891466 debug extra libmpv-dbg_0.5.1-1_amd64.deb 0516106e2a29abd06c8b405b35440827 2827 video optional mpv_0.5.1-1.dsc 959e0de851b313ff4c7b11aa66e441de 2578385 video optional mpv_0.5.1.orig.tar.gz 131c6421024e9157f5d4c5f0aad44c5b 91860 video optional mpv_0.5.1-1.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJT/Z/RAAoJEK+lG9bN5XPLDIwQAJhxc0J5oidpnCKhltboGrwF 0Y8t6htBaiiciafwsNNKV9OSwCahvxXyw6kE07OrxgeYb/oeM8mochWvYy6Z09un 1G3k5Dr5pKxWVNhguPGezjPGM3F2KG4fIfV4qyS1/N8hwh+jKFeK7bT4Aeo9k4G1 FB73//FCuVqA0tXpFhiknH1sQXgyn8MqNJHW/xzKmt58SYuBq3LhjRViJC9ja2aJ YVN7RXmnK4ij2hqEs3aBKB9+FYFMxxOXzzZ1synRiIfsV6Z3t1cPD7HSiQT/4PYj XvmrMrgWPtPRxfPXp3Ul5Pv5/MHOIpLUlC0DmyjXxLNOOXCn7UWRIht6EhxNyYnp mmTCJhVBQ1bm2ygq2NeB5kRqIECtZGwqXvXbefxR2BD08vkEnzFZncjDPTALqCrp 82ptXQ9MdbUJ6NTwM+QrIkqzeo2bPmeOEJQnH6LzqojOROlbrRPkX1rPayIgHAmt TX7z0V3hS4kDWLVIef18ry7qkvvcgVnixe2E97uZGRo744t5s5HvaqfweYVwSL6U bikREjjv1D+C3DvzdywxtVX2ahu34v7es+WJAGtdAhixTFijhrpioNR7UNywg+w3 EqV0vjjh7o2qkmkya+L5IDcOiL7H3uAmykVRYkkXYHM/mGtrzmylRLW8fOXxb267 Wx6rspxAartG7QkkcP2K =nOW9 -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ 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: Select provider of libav* libraries
Hi Matteo, 2014-08-27 11:11 GMT+02:00 Matteo F. Vescovi mfvesc...@gmail.com: Hi! On 2014-08-27 at 10:54 (CEST), Bálint Réczey wrote: If the definition of being crazy is something close to being irrational then making decisions based only on sunken costs can hardly be shown to be the opposite. :-) OTOH it is very human. :-) Don't get me wrong: it's clear that if the effort would bring to something relevant, I'd be the first to say hey, ok... let's do it now! but, at the present time, I don't see any relevant benefit from the switch, at least on my side (that is limited to a couple of packages, by the way). It is a perfectly fine reasoning. I just wanted to point out that many people (not just you and I did not want to be personal) consider the time spent in the past instead of the time to be spent in the future in the decision which is not the best approach. I myself don't _want_ Debian to switch and especially not _now_, but would like to ask everyone to consider the future gains/costs related to maintaining Libav/FFmpeg instead of looking at how we spent countless nights on keeping Libav working with all upstreams. AFAICT, Blender upstream was (and probably is still) a big fan of FFmpeg library, been that used as default in their code. But they were also proficient in getting Libav working good and smooth in latest upstream releases. So, probably there won't be any evident difference between those two libraries in packaging. I could do some test buildings against FFmpeg once it hits the experimental suite (or whatever). I think the gains from Libav/FFmpeg are on par but the costs of maintaining Libav is higher since most upstreams (personal judgement, not backed by hard data) prefer and test FFmpeg. But, as a human being with a real-world-life, I'd prefer spending my spare time with my son than fixing FTBFS on Blender due to FFmpeg ;-P We are no different from this aspect, I would like to make Debian's Multimedia offering as pleasant as possible in the least amount of time spent on it. I see a big advantage in using the libs upstreams are testing their code against. I also think that keeping FFmpeg out of the archive is not fair. I would like to have it accepted by FTP Masters even if it is not going to be part of Jessie. Cheers, Balint ___ 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: Select provider of libav* libraries
On Wed, Aug 27, 2014 at 10:54:09AM +0200, Bálint Réczey wrote: Hi, 2014-08-27 9:52 GMT+02:00 Matteo F. Vescovi mfvesc...@gmail.com: Hi Team! On 2014-08-27 at 00:36 (CEST), Benjamin Drung wrote: [...] So I am asking you: Should we ship libav or FFmpeg? Can we reach a consensus on this topic? Libav for me, of course. I've spent too much time on getting it working fine with Blender that it'd be crazy to change it now. ;-) If the definition of being crazy is something close to being irrational then making decisions based only on sunken costs can hardly be shown to be the opposite. :-) Wow! So time, energy, and effort are *just* sunken¹ costs? :( ¹ Whatever sunken means. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X ___ 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: Select provider of libav* libraries
2014-08-27 11:40 GMT+02:00 Chris Bannister cbannis...@slingshot.co.nz: On Wed, Aug 27, 2014 at 10:54:09AM +0200, Bálint Réczey wrote: Hi, 2014-08-27 9:52 GMT+02:00 Matteo F. Vescovi mfvesc...@gmail.com: Hi Team! On 2014-08-27 at 00:36 (CEST), Benjamin Drung wrote: [...] So I am asking you: Should we ship libav or FFmpeg? Can we reach a consensus on this topic? Libav for me, of course. I've spent too much time on getting it working fine with Blender that it'd be crazy to change it now. ;-) If the definition of being crazy is something close to being irrational then making decisions based only on sunken costs can hardly be shown to be the opposite. :-) Wow! So time, energy, and effort are *just* sunken¹ costs? :( ¹ Whatever sunken means. Well, sunk. :-) ___ 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: Select provider of libav* libraries
Quoting Benjamin Drung (2014-08-27 00:36:09) Should we ship libav or FFmpeg? For upcoming Jessie release: Libav (too risky to change this late!) Can we reach a consensus on this topic? Highly doubtful - expect us to only reach democratic majority. - 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: 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
libaudclient_3.5~rc2-1_i386.changes REJECTED
Dear Maintainer, unfortunately you forgot to update your debian/copyright after the split and the new license is missing. Thorsten === 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Tue, Aug 26, 2014 at 6:47 PM, Reinhard Tartler siret...@gmail.com wrote: On Tue, Aug 26, 2014 at 6:36 PM, Benjamin Drung bdr...@debian.org wrote: Hi, there was a discussion on the debian-devel mailing list about reintroducing FFmpeg to Debian [1]. The security team made clear [2] that they will only support one provider of the libav* libraries. So either libav or FFmpeg could go in the release and the other library has to stay in experimental (or unstable with a RC bug). The maintainer of libav is the Debian Multimedia team and therefore it is up to us to decide whether we want libav or FFmpeg in Debian 8 (jessie). So I am asking you: Should we ship libav or FFmpeg? Libav, see my previous emails that I posted on this mailing list on this topic for rationale. What I've found missing in the recent discussion is the approach to releases, which was a factor back in the day. If I recall correctly, libav has a release process and a merge policy that was better for a stable distro. I'm fuzzy on the details, though. Is this difference still so? -- Saludos, Felipe Sateler ___ 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: Select provider of libav* libraries
Am Mittwoch, den 27.08.2014, 09:52 +0200 schrieb Matteo F. Vescovi: Libav for me, of course. I am for libav for the next stable release. However, I am open for anything else after that. To be honest, I recently find the sheer number of my bug instantly vanished once I replaced libav with ffmpeg reports a bit emberrassing. I've spent too much time on getting it working fine with Blender that it'd be crazy to change it now. ;-) Then Bálint must clearly be crazy to do all the porting work the other way round for XBMC. ;) - Fabian ___ 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: Select provider of libav* libraries
On Aug 27, 2014 10:43 AM, Fabian Greffrath fab...@greffrath.com wrote: Am Mittwoch, den 27.08.2014, 09:52 +0200 schrieb Matteo F. Vescovi: Libav for me, of course. I am for libav for the next stable release. However, I am open for anything else after that. To be honest, I recently find the sheer number of my bug instantly vanished once I replaced libav with ffmpeg reports a bit emberrassing. Did you check how many of those bugs are fixed in a later libav upstream release? Note that even the current libav release frequency is tough for Debian, even faster releases won't make integration any easier. I've spent too much time on getting it working fine with Blender that it'd be crazy to change it now. ;-) Then Bálint must clearly be crazy to do all the porting work the other way round for XBMC. ;) Xbmc works best with its embedded copy of FFmpeg. I predict similar problems with an outdated system copy of FFmpeg. The time spent in fixing that does not seem significantly smaller than fixing bugs in libav. Best Reinhard ___ 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: Select provider of libav* libraries
On Wed, Aug 27, 2014 at 10:43 AM, Reinhard Tartler siret...@gmail.com wrote: On Aug 27, 2014 10:28 AM, Felipe Sateler fsate...@debian.org wrote: On Tue, Aug 26, 2014 at 6:47 PM, Reinhard Tartler siret...@gmail.com wrote: On Tue, Aug 26, 2014 at 6:36 PM, Benjamin Drung bdr...@debian.org wrote: Hi, there was a discussion on the debian-devel mailing list about reintroducing FFmpeg to Debian [1]. The security team made clear [2] that they will only support one provider of the libav* libraries. So either libav or FFmpeg could go in the release and the other library has to stay in experimental (or unstable with a RC bug). The maintainer of libav is the Debian Multimedia team and therefore it is up to us to decide whether we want libav or FFmpeg in Debian 8 (jessie). So I am asking you: Should we ship libav or FFmpeg? Libav, see my previous emails that I posted on this mailing list on this topic for rationale. What I've found missing in the recent discussion is the approach to releases, which was a factor back in the day. If I recall correctly, libav has a release process and a merge policy that was better for a stable distro. I'm fuzzy on the details, though. Is this difference still so? Well, I still act as upstream release manager and do spend most of my time with making sure that all upstream release fit into the Debian release cycle. For instance I've strongly pushed for the recent libav11 beta so that we can start the transition in time. I also am in charge for the the stable point releases including the uploads to stable-security in the last three years or so. In that context, I'm making sure that point releases only contain code changes that are acceptable for stable-security. That is excellent news, and I'm not sure the wider audience knows this. For comparison, do you know how the ffmpeg release process works? -- Saludos, Felipe Sateler ___ 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 be verbose whether you would like to get your Blend promoted by tasksel
On Tue, Aug 26, 2014 at 7:27 AM, Andreas Tille andr...@an3as.eu wrote: Hi, yesterday I joined the videostream of the installer BoF at DebConf[1]. I also became a bit involved via IRC. Joey Hess raised the question about the criteria to add a Blend or not. I answered all in the list of the bug report #758116 which IMHO fits the criterion of actively maintained and some valuable content for users. I think it should be also a criterion that the team behind the Blend confirms that they are interested and so I'm hereby pinging all lists in question to ask you for confirmation. Do we want to pursue this? I think that if we could manage to provide useful blend packages it would be worth it, but so far I have failed to do so. I think maybe we need to rethink the approach and reduce the number of metapackages. Today we have too many. Maybe we should reduce them to 2: multimedia-codecs and multimedia-production. The first would depend on all the codec-prividing packages, so that we can tell users: install this and every media file on the internets is playable. Today we might have some files not playable in some media players by default because (for example) the appropriate gstreamer-* was not installed or some other nonsense. Hopefully, the internets will fill up with install multimedia-codecs instead of add deb-multimedia instructions. The second should provide pretty much every multimedia production related application we have, plus ladspa and LV2 plugins. This is more likely to be more useful to add to tasksel than the first metapackage. Ideally this would make debian a competitor to kxstudio or avstudio. I think we have some way to go before we are at their level, but that doesn't mean we shouldn't try. Ideally we could get them (the downstreams) to work with us and simply modify and package additional things we do not (or cannot) have in Debian. What do you think? This is the current git repo for the blend: http://anonscm.debian.org/cgit/pkg-multimedia/multimedia-blends.git/ -- Saludos, Felipe Sateler ___ 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 be verbose whether you would like to get your Blend promoted by tasksel
Quoting Felipe Sateler (2014-08-27 17:19:27) On Tue, Aug 26, 2014 at 7:27 AM, Andreas Tille andr...@an3as.eu wrote: yesterday I joined the videostream of the installer BoF at DebConf[1]. I also became a bit involved via IRC. Joey Hess raised the question about the criteria to add a Blend or not. I answered all in the list of the bug report #758116 which IMHO fits the criterion of actively maintained and some valuable content for users. I think it should be also a criterion that the team behind the Blend confirms that they are interested and so I'm hereby pinging all lists in question to ask you for confirmation. Do we want to pursue this? I think that if we could manage to provide useful blend packages it would be worth it, but so far I have failed to do so. I think maybe we need to rethink the approach and reduce the number of metapackages. Today we have too many. Maybe we should reduce them to 2: multimedia-codecs and multimedia-production. When this blend emerged I was surprised it only grouped by functionality - I imagine few users need 8 ways to loop audio or 7 drum machines, and more need either a rich drum-machine and rudimentary other tools missing from that specific tool relevant for drum-oriented production or a rich loop engine and rudimentary add-on tools missing from that specific tool relevant for loop-oriented multimedia production. Each such scenario-oriented would have the potential to grow from simple metapackage to also include choice of window manager and custom tuning of that to optimize for the scenario, and suitable Gtk+ and Qt skin, and some graphics that goes well with it. I.e. spice not technically multimedia but part of a multimedia user experience. The games team has created metapackages grouped by gaming style, but also done a few subjective selections. That I find inspiring. Perhaps leave all the current multimedia metapackages as-is, but add additional subjective ones each composing an _environment_ for consuming/producing multimedia. Also consuming multimedia is IMO relevant to group like that: When using KDE (and therefore libphonon) what is recommended players and codec packages and whatever to use together? How about a lightweight (i.e. non-GNOME and non-KDE) desktop - what do we recommend to use there? For the DebianParl blend (which uses Xfce desktop) I have experimented with avoiding GStreamer framework altogether. That is possible - and is quite lightweight. Specifically your idea to create a multimedia-codecs: I think few user really wants all codecs in the FLOSS World - that's merely the desparate consequence of all relevant FLOSS codecs installed and properly registered too often missing. Let's fix the real problem, not encourage our users to bogusly reframe it. - 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: 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
libdvdnav 5.0.0-1 MIGRATED to testing
FYI: The status of the libdvdnav source package in Debian's testing distribution has changed. Previous version: 4.2.1-3 Current version: 5.0.0-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 https://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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
guayadeque 0.3.7~ds0-2.1 MIGRATED to testing
FYI: The status of the guayadeque source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 0.3.7~ds0-2.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 https://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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#759499: [guayadeque] crashes while scanning a collection
Package: guayadeque Version: 0.3.7~ds0-2.1 Severity: important One of my three collections makes crash guayadeque while scanning. This is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffdf7fe700 (LWP 4979)] __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36 36 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36 #1 0x75537d47 in TagLib::ByteVector::replace(TagLib::ByteVector const, TagLib::ByteVector const) () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #2 0x7550a0e9 in TagLib::ID3v2::SynchData::decode(TagLib::ByteVector const) () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #3 0x755097ed in TagLib::ID3v2::FrameFactory::createFrame(TagLib::ByteVector const, TagLib::ID3v2::Header*) const () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #4 0x7550dadf in TagLib::ID3v2::Tag::parse(TagLib::ByteVector const) () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #5 0x7550dd79 in TagLib::ID3v2::Tag::read() () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #6 0x7550de87 in TagLib::ID3v2::Tag::Tag(TagLib::File*, long, TagLib::ID3v2::FrameFactory const*) () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #7 0x7553e6b4 in TagLib::FLAC::File::read(bool, TagLib::AudioProperties::ReadStyle) () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #8 0x7553e9e0 in TagLib::FLAC::File::File(char const*, bool, TagLib::AudioProperties::ReadStyle) () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #9 0x75565e60 in TagLib::FileRef::create(char const*, bool, TagLib::AudioProperties::ReadStyle) () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #10 0x75566b85 in TagLib::FileRef::FileRef(char const*, bool, TagLib::AudioProperties::ReadStyle) () from /usr/lib/x86_64-linux-gnu/libtag.so.1 #11 0x00637a8a in guTagInfo::SetFileName (this=this@entry=0x7fffd0464060, filename=...) at /build/guayadeque-cXepIy/guayadeque-0.3.7~ds0/src/TagInfo.cpp:705 #12 0x00638020 in guTagInfo::guTagInfo (this=this@entry=0x7fffd0464060, filename=...) at /build/guayadeque-cXepIy/guayadeque-0.3.7~ds0/src/TagInfo.cpp:681 #13 0x006381be in guFlacTagInfo::guFlacTagInfo (this=this@entry=0x7fffd0464060, filename=...) at /build/guayadeque-cXepIy/guayadeque-0.3.7~ds0/src/TagInfo.cpp:1672 #14 0x00638758 in guGetTagInfoHandler (filename=...) at /build/guayadeque-cXepIy/guayadeque-0.3.7~ds0/src/TagInfo.cpp:94 #15 0x00502fc9 in guDbLibrary::ReadFileTags (this=0xd96d00, filename=..., allowrating=allowrating@entry=false) at /build/guayadeque-cXepIy/guayadeque-0.3.7~ds0/src/DbLibrary.cpp:1824 #16 0x00677d65 in guLibUpdateThread::Entry (this=0x1283d60) at /build/guayadeque-cXepIy/guayadeque-0.3.7~ds0/src/LibUpdate.cpp:305 #17 0x77b017b2 in wxThread::CallEntry() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #18 0x77b020b4 in ?? () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #19 0x7341f0a4 in start_thread (arg=0x7fffdf7fe700) at pthread_create.c:309 #20 0x73b35fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) --- System information. --- Architecture: amd64 Kernel: Linux 3.16.1 Debian Release: jessie/sid 500 testing ftp.debian.org 500 stable security.debian.org --- Package information. --- Depends (Version) | Installed ===-+-= gstreamer0.10-plugins-base | 0.10.36-1.1 gstreamer0.10-plugins-good | 0.10.31-3+nmu3 libc6 (= 2.14) | 2.19-9 libcurl3-gnutls (= 7.16.2) | 7.37.1-1 libdbus-1-3 (= 1.0.2) | 1.8.6-2 libgcc1(= 1:4.1.1) | 1:4.9.1-4 libgdk-pixbuf2.0-0 (= 2.22.0) | 2.30.7-1 libglib2.0-0(= 2.22.0) | 2.40.0-4 libgpod4 (= 0.7.0) | 0.8.3-1.1+b1 libgstreamer0.10-0 (= 0.10.11) | 0.10.36-1.3 libindicate5(= 0.4.90) | 0.6.92-2 libstdc++6 (= 4.6) | 4.9.1-4 libtag1c2a (= 1.7) | 1.9.1-2.1 libwxbase3.0-0 (= 3.0.1) | 3.0.1-3 libwxgtk3.0-0(= 3.0.1) | 3.0.1-3 libwxsqlite3-3.0-0 | 3.1.0~dfsg1-1.1 Package's Recommends field is empty. Package's Suggests field is empty. -- Best Regards, -- Manolo Díaz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
failed ppc64el build of mpeg2dec 0.5.1-5
* Source package: mpeg2dec * Version: 0.5.1-5 * Architecture: ppc64el * State: failed * Suite: sid * Builder: ppc64el1.debian.net * Build log: https://buildd.debian.org/fetch.cgi?pkg=mpeg2decarch=ppc64elver=0.5.1-5stamp=1409169421file=log Please note that these notifications do not necessarily mean bug reports in your package but could also be caused by other packages, temporary uninstallabilities and arch-specific breakages. A look at the build log despite this disclaimer would be appreciated however. ___ 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: git-packaging workflows
On Sat, Aug 23, 2014 at 9:53 AM, Reinhard Tartler siret...@gmail.com wrote: On Fri, Aug 22, 2014 at 11:08 AM, Felipe Sateler fsate...@debian.org wrote: Resurrecting an old thread On Sat, Apr 6, 2013 at 4:32 AM, Reinhard Tartler siret...@gmail.com wrote: Hi, Recently, Russ' blog post was echoed on http://planet.debian.org: http://www.eyrie.org/~eagle/journal/2013-04/001.html In that post, he describes how to combine both the import tarball and the have upstream history available in the upstream packaging branch. AFAIUI, the heavy work is implemented in git-buildpackage's --upstream-vcs-tag tag option. While that option is news to me, I wonder if maybe anyone else already experiments with this? Does the team feel that making it mandatory for our package would be beneficial and appropriate? I know some in the team have experimented with this new workflow. Could you share your experiences with it? I'm thinking that we should encourage this workflow a bit more: it makes collaboration with upstream easier (in both directions). However I'm still not too clear on what would it look like, so I'd like to hear from people that have been using it about their thoughts. I've been using that for libav, and am comfortable with it. The caveats that I've found so far: 1. you need to manually add a named remote (git remote add upstream «upstream_git_url» git remote update upstream) Yes, that is indeed required. 2. you need to identify the upstream tag and must not forget to pass it to git-import-orig --upstream-vcs-tag The first one could be scripted, I guess. Doesn't gbp have an option to autoguess the upstream vcs tag? Questions of interest: are you using gbp pq? If not, how do you pick patches from upstream? How do you post patches back to upstream? I do think we need to somehow restrict the commits that get posted on the commit list. Sometimes we get a mailbomb of new commits... :p Yes, that's the third caveat. I promised at some point to have a look at the mail hook, but didn't find the time. Sorry I think I will adopt this scheme for some of my packages. However, I will wait until this is resolved (I don't have time to look into this). Perhaps we can filter commits that touch the debian/ dir? Also, I'll start experimenting with the patch-queue feature of gbp. Thanks to all for your responses -- Saludos, Felipe Sateler ___ 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: Select provider of libav* libraries
Hi, 2014-08-27 16:52 GMT+02:00 Reinhard Tartler siret...@gmail.com: On Aug 27, 2014 10:43 AM, Fabian Greffrath fab...@greffrath.com wrote: Am Mittwoch, den 27.08.2014, 09:52 +0200 schrieb Matteo F. Vescovi: Libav for me, of course. I am for libav for the next stable release. However, I am open for anything else after that. To be honest, I recently find the sheer number of my bug instantly vanished once I replaced libav with ffmpeg reports a bit emberrassing. Did you check how many of those bugs are fixed in a later libav upstream release? Note that even the current libav release frequency is tough for Debian, even faster releases won't make integration any easier. If Libav 11 fixes #742896 and #741170 I will be very happy. I've spent too much time on getting it working fine with Blender that it'd be crazy to change it now. ;-) Then Bálint must clearly be crazy to do all the porting work the other way round for XBMC. ;) Xbmc works best with its embedded copy of FFmpeg. I predict similar problems with an outdated system copy of FFmpeg. The time spent in fixing that does not seem significantly smaller than fixing bugs in libav. While it is true that XBMC builds with an internal FFmpeg copy they switched a vanilla version instead of carrying many patches themselves. Usually they target latest stable release. For Debian if we can update to the latest XBMC right before the freeze (I can assure that) and we update to latest FFmpeg at the same time (FFmpeg maintainer probably targets this as well) then we don't have to do extra work, upstream already performed the integration. I don't know how much time is needed for fixing Libav bugs affecting XBMC, but if they are as easy as switching to FFmpeg, then please push their resolution upstream. Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed (with 1 errors): Re: Bug#752544: vlc: source package fails to compile
Processing control commands: severity -1 serious Bug #752544 [vlc] vlc: source package fails to compile Severity set to 'serious' from 'normal' tags -1 + forwarded-upstream pending Unknown tag/s: forwarded-upstream. Recognized are: patch wontfix moreinfo unreproducible fixed potato woody sid help security upstream pending sarge sarge-ignore experimental d-i confirmed ipv6 lfs fixed-in-experimental fixed-upstream l10n etch etch-ignore lenny lenny-ignore squeeze squeeze-ignore wheezy wheezy-ignore jessie jessie-ignore. Bug #752544 [vlc] vlc: source package fails to compile Added tag(s) pending. -- 752544: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752544 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of libaudclient_3.5~rc2-1_i386.changes
libaudclient_3.5~rc2-1_i386.changes uploaded successfully to localhost along with the files: libaudclient-dev_3.5~rc2-1_i386.deb libaudclient2_3.5~rc2-1_i386.deb libaudclient_3.5~rc2-1.dsc libaudclient_3.5~rc2.orig.tar.bz2 libaudclient_3.5~rc2-1.debian.tar.xz 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
libaudclient_3.5~rc2-1_i386.changes is NEW
binary:libaudclient-dev is NEW. source:libaudclient is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#752544: vlc: source package fails to compile
Processing control commands: reassign -1 src:glib2.0 2.40.0-4 Bug #752544 [vlc] vlc: source package fails to compile Bug reassigned from package 'vlc' to 'src:glib2.0'. No longer marked as found in versions vlc/2.1.4-1. Ignoring request to alter fixed versions of bug #752544 to the same values previously set Bug #752544 [src:glib2.0] vlc: source package fails to compile Marked as found in versions glib2.0/2.40.0-4. retitle -1 glib2.0: build gobject with -Wl,nodelete to prevent unloading Bug #752544 [src:glib2.0] vlc: source package fails to compile Changed Bug title to 'glib2.0: build gobject with -Wl,nodelete to prevent unloading' from 'vlc: source package fails to compile' tags -1 = upstream fixed-upstream Bug #752544 [src:glib2.0] glib2.0: build gobject with -Wl,nodelete to prevent unloading Added tag(s) upstream and fixed-upstream; removed tag(s) pending. affects -1 vlc Bug #752544 [src:glib2.0] glib2.0: build gobject with -Wl,nodelete to prevent unloading Added indication that 752544 affects vlc -- 752544: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752544 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
