Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
It looks like the crystalhd drivers are buggy with newer kernel releases. I opt for removing the dkms package. I will do this over the weekend. On Thu, Feb 28, 2013 at 4:52 PM, thomas schorpp thomas.scho...@gmail.com wrote: On 28.02.2013 20:41, Julien Cristau wrote: On Thu, Jan 31, 2013 at 19:25:50 +0100, tom schorpp wrote: Package: crystalhd-dkms Version: 1:0.0~git20110715.fdd2f19-7 Severity: critical Tags: patch Justification: breaks the whole system Reproducible NULL pointer BUG at crystalhd-0.0~git20110715.fdd2f19/driver/linux/crystalhd_misc.c:515, triggered by adobe flash plugin from dmo repo, ffmpeg, mplayer, bino or other, mostly on heavy ioq usage or after FETCH_TIMEOUT and/or unclosed driver HANDLEs. Does the maintainer or somebody on pkg-multimedia plan on fixing this RC bug? If not I'll consider a NMU removing the dkms package from crystalhd source. Cheers, Julien Known linux-media Maintainers STAGING - CRYSTAL HD VIDEO DECODER M:Naren Sankar nsan...@broadcom.com M:Jarod Wilson ja...@wilsonet.com M:Scott Davilla davi...@4pi.com M:Manu Abraham abraham.m...@gmail.com seem to have left the Broadcom's legacy driver code, focusing on the new linux-media staging driver, but limited time, one stated lately on the linux-media/LKML, nothing read from the others. I could adapt it to new kernel releases the next 2-3 years, but nothing more, not a experienced kernel driver coder, no debian package/policy maintaining motivation because I do not use dkms or debian kernels packages. If my last patch applies to Your codebase in the debian git repository (mine is from git.linuxtv.org, according to the git changelog more advanced in the gstreamer plugin, merge?) You may consider it hotfixed and release with known multithreading (gstreamer based transcoders/matroska demuxers) and PM ACPI S3 issues? Has not crashed here any more, nor notable side effects with usual playback use cases, including Totem (gstreamer). y tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- ~ Andres ___ 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: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On Fri, Mar 1, 2013 at 3:55 PM, Julien Cristau jcris...@debian.org wrote: On Fri, Mar 1, 2013 at 21:38:54 +0100, thomas schorpp wrote: So no technical reasons to drop the package? Until and unless the driver is in mainline, there's every reason to drop it. Cheers, Julien I just checked the crystalhd driver in the mainline kernel. The driver seems to be much better maintained over there than at linuxtv.org. See [1]. I'm going to drop the driver from linuxtv.org. If after I drop the package someone has some compelling reason to use the driver from linuxtv.org, they can submit another bug to the crystalhd package and explain why the linuxtv.org driver should be used. 1. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/staging/crystalhd -- ~ Andres ___ 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: xbmc_12.0~git20121119.22795bc-1_amd64.changes ACCEPTED into experimental
On Sat, Nov 24, 2012 at 2:09 AM, Reinhard Tartler siret...@gmail.com wrote: On Fri, Nov 23, 2012 at 8:26 PM, Andres Mejia amejia...@gmail.com wrote: On Thu, Nov 22, 2012 at 1:11 AM, Reinhard Tartler siret...@gmail.com wrote: On Tue, Nov 20, 2012 at 1:12 AM, Andres Mejia amejia...@gmail.com wrote: On Mon, Nov 19, 2012 at 7:07 PM, Andres Mejia amejia...@gmail.com wrote: Hi all, FYI, I uploaded a new version of XBMC. I'm notifying you all because of a major change. This version of XBMC will be built and run using XBMC's internal copy of FFMpeg (the 10.2 branch of FFMpeg that is). Due to the number of changes done between FFMpeg and Libav (particularly with libavfilter), it would have taken an enormous amount of work to try and get XBMC building and running using Libav. Also, I did forget to note this major change in the changelog, but I did add a NEWS entry for this. Sorry about that. Also as an aside, I think we should discuss how to get ffmpeg back into Debian again. As I said some time ago, either Libav, FFMpeg, or both have to get their libraries and header paths renamed. I also want to note this now, apparently chromium has been using it's own internal copy of FFMpeg for some time now. Therefore, XBMC is not the first package where using an internal ffmpeg is being done. Are you sure that all involved developers, including chromium xbmc upstream as well as their packagers, would agree on the same FFmpeg snapshot? I don't believe anyone ever mentioned that these two projects should use the same snapshot of ffmpeg. Well, it is out of question that having many different versions of a library such as libavcodec is not acceptable for a stable Debian release. FYI, I've asked on IRC the release team and the security team about that. The security team referred to the security team, who respond with: 23:47 gilbert_ siretart: iuculano made the switch to embedded libav. his plan is to bump chromium to each new upstream throughout wheezy's support lifetime, and having the embedded library makes that a lot more feasible. my opinion is to not release chromium in stable at all since even that is going to way too much work, but i've been overrulled. seems people actually want chromium in stable... Chromium is not a good precedent at all. The maintainer has even joined the security team for having and maintaining it in stable. Moreover, you have to keep in mind that most security issues and fixes do come from chromium upstream. Therefore, this is hardly an excuse for xbmc for handling and outdated, internal copy of FFmpeg in a distribution package. TBH, I'm very skeptical. And with FFmpeg releasing like crazy after the fork, I don't see the project suitable at all for a distro scenario such as Debian. For instance, you indicate that XBMC uses the 0.10 branch; the latest upstream release, however, is 1.0, the release before is 0.11. Chromium maintains it (defacto) own branch, which admittedly is based on FFmpeg master. Therefore, tracking upstream releases does not seem to accommodate either project. To conclude, I understand that xbmc is causing new challenges here, but TBH, I think the better solution would be to investigate what's missing in libav's libavfilter. For instance, I think you mean the audio filter still, which has landed in libav 9. I imagine that there is still some stuff missing, but if it is useful, I'm sure it can be submitted libav upstream. -- regards, Reinhard I don't work on the components of xbmc that uses ffmpeg. Elupus is who you want to speak to. You can either try the xbmc-dev channels or the xbmc forums to reach out to him to see what (if anything) libav could do so xbmc could work with libav. Sorry, I definitely do not have the resources to engage with xbmc, at least not at this point, as I am more than busy with preparing stable libav releases and getting the libav 9 transition going in ubuntu, here is the current progress: https://launchpad.net/~motumedia/+archive/libav9-raring/+packages Help would be more than welcome. To conclude, the fact that the xbmc source package bundles FFmpeg is an RC bug to me that hinders its acceptance jessie. This means that I have no problems having such a copy in experimental, or even unstable, but just not in testing. BTW, we have a similar problem with mplayer, were I have the very same opinion. -- regards, Reinhard I think you meant to respond in the mailing lists. Thanks for your input. -- ~ Andres ___ 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: xbmc_12.0~git20121119.22795bc-1_amd64.changes ACCEPTED into experimental
On Thu, Nov 22, 2012 at 1:11 AM, Reinhard Tartler siret...@gmail.com wrote: On Tue, Nov 20, 2012 at 1:12 AM, Andres Mejia amejia...@gmail.com wrote: On Mon, Nov 19, 2012 at 7:07 PM, Andres Mejia amejia...@gmail.com wrote: Hi all, FYI, I uploaded a new version of XBMC. I'm notifying you all because of a major change. This version of XBMC will be built and run using XBMC's internal copy of FFMpeg (the 10.2 branch of FFMpeg that is). Due to the number of changes done between FFMpeg and Libav (particularly with libavfilter), it would have taken an enormous amount of work to try and get XBMC building and running using Libav. Also, I did forget to note this major change in the changelog, but I did add a NEWS entry for this. Sorry about that. Also as an aside, I think we should discuss how to get ffmpeg back into Debian again. As I said some time ago, either Libav, FFMpeg, or both have to get their libraries and header paths renamed. I also want to note this now, apparently chromium has been using it's own internal copy of FFMpeg for some time now. Therefore, XBMC is not the first package where using an internal ffmpeg is being done. Are you sure that all involved developers, including chromium xbmc upstream as well as their packagers, would agree on the same FFmpeg snapshot? I don't believe anyone ever mentioned that these two projects should use the same snapshot of ffmpeg. TBH, I'm very skeptical. And with FFmpeg releasing like crazy after the fork, I don't see the project suitable at all for a distro scenario such as Debian. For instance, you indicate that XBMC uses the 0.10 branch; the latest upstream release, however, is 1.0, the release before is 0.11. Chromium maintains it (defacto) own branch, which admittedly is based on FFmpeg master. Therefore, tracking upstream releases does not seem to accommodate either project. To conclude, I understand that xbmc is causing new challenges here, but TBH, I think the better solution would be to investigate what's missing in libav's libavfilter. For instance, I think you mean the audio filter still, which has landed in libav 9. I imagine that there is still some stuff missing, but if it is useful, I'm sure it can be submitted libav upstream. -- regards, Reinhard I don't work on the components of xbmc that uses ffmpeg. Elupus is who you want to speak to. You can either try the xbmc-dev channels or the xbmc forums to reach out to him to see what (if anything) libav could do so xbmc could work with libav. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Fwd: xbmc_12.0~git20121119.22795bc-1_amd64.changes ACCEPTED into experimental
Hi all, FYI, I uploaded a new version of XBMC. I'm notifying you all because of a major change. This version of XBMC will be built and run using XBMC's internal copy of FFMpeg (the 10.2 branch of FFMpeg that is). Due to the number of changes done between FFMpeg and Libav (particularly with libavfilter), it would have taken an enormous amount of work to try and get XBMC building and running using Libav. Also, I did forget to note this major change in the changelog, but I did add a NEWS entry for this. Sorry about that. Also as an aside, I think we should discuss how to get ffmpeg back into Debian again. As I said some time ago, either Libav, FFMpeg, or both have to get their libraries and header paths renamed. -- Forwarded message -- From: Debian FTP Masters ftpmas...@ftp-master.debian.org Date: Mon, Nov 19, 2012 at 6:49 PM Subject: xbmc_12.0~git20121119.22795bc-1_amd64.changes ACCEPTED into experimental To: Debian XBMC Packaging Team pkg-xbmc-maintain...@lists.alioth.debian.org, Andres Mejia ame...@debian.org Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 19 Nov 2012 17:56:50 -0500 Source: xbmc Binary: xbmc xbmc-bin xbmc-eventclients-common xbmc-eventclients-dev xbmc-eventclients-wiiremote xbmc-eventclients-j2me xbmc-eventclients-ps3 xbmc-eventclients-xbmc-send Architecture: source all amd64 Version: 2:12.0~git20121119.22795bc-1 Distribution: experimental Urgency: low Maintainer: Debian XBMC Packaging Team pkg-xbmc-maintain...@lists.alioth.debian.org Changed-By: Andres Mejia ame...@debian.org Description: xbmc - XBMC Media Center (arch-independent data package) xbmc-bin - XBMC Media Center (binary data package) xbmc-eventclients-common - XBMC Media Center (Event Client Common package) xbmc-eventclients-dev - XBMC Media Center (Event Client Dev package) xbmc-eventclients-j2me - XBMC Media Center (Event Client J2ME package) xbmc-eventclients-ps3 - XBMC Media Center (Event Client PS3 package) xbmc-eventclients-wiiremote - XBMC Media Center (Event Client WII Remote support package) xbmc-eventclients-xbmc-send - XBMC Media Center (Event Client XBMC-SEND package) Closes: 668901 681264 682312 685076 Changes: xbmc (2:12.0~git20121119.22795bc-1) experimental; urgency=low . * New upload for beta packages of XBMC Frodo. (Closes: #668901) (Closes: #681264) (Closes: #682312) * Recommends of python-qt3 is removed. (Closes: #685076) Checksums-Sha1: 8472b46a10e73a90c428bc6d328f3f7de38a97ea 3810 xbmc_12.0~git20121119.22795bc-1.dsc 938f168c780f803458cbda5eccfae1ec8860fbaf 54951931 xbmc_12.0~git20121119.22795bc.orig.tar.gz 3ad956b4addf812564d4c454b7028a2dbe7caf7e 37398 xbmc_12.0~git20121119.22795bc-1.debian.tar.gz dfd5c97e7ae3454af7f847fc26edf2f2082681db 21034010 xbmc_12.0~git20121119.22795bc-1_all.deb 4775e819446e436fba099b24eb6b577443a6af72 12077902 xbmc-bin_12.0~git20121119.22795bc-1_amd64.deb 81eefc8af233af513bd1714b5661f7cc3b5ab046 58012 xbmc-eventclients-common_12.0~git20121119.22795bc-1_all.deb e965b33bdc6fa6ff5b96859bcf4bf4844f682177 43332 xbmc-eventclients-dev_12.0~git20121119.22795bc-1_all.deb d81d331b436b68222d0774a6f4c1172389f600fb 61958 xbmc-eventclients-wiiremote_12.0~git20121119.22795bc-1_amd64.deb e620156fd4ae08b717a61bb4a2b807d18f902226 36410 xbmc-eventclients-j2me_12.0~git20121119.22795bc-1_all.deb 8eed3ec12c397346e544684a94b3e8abaa299613 36834 xbmc-eventclients-ps3_12.0~git20121119.22795bc-1_all.deb 11f4feae4ca1258edea2c13fd6f925efbb95a31a 35654 xbmc-eventclients-xbmc-send_12.0~git20121119.22795bc-1_all.deb Checksums-Sha256: 8a92846117224aea5e431abe73d8011b104528ab8cd54e40b3b6c6a199a1d4b4 3810 xbmc_12.0~git20121119.22795bc-1.dsc 777e5be318a901ec84914bb1029983d233ba615c7f6b71d8fd1191b7a5f83cb4 54951931 xbmc_12.0~git20121119.22795bc.orig.tar.gz 7cc5f5a2ed68ccbfb1660420f06372d1832bd56ed04ed31d03e5e2e5e1699ec0 37398 xbmc_12.0~git20121119.22795bc-1.debian.tar.gz ee3466c532549979154bc0aea70d047fafb49ad800e8358985dbc0bf63c14222 21034010 xbmc_12.0~git20121119.22795bc-1_all.deb d0502b10e7a7e9beb16e36929e86dd491fe7d62d6d70e6d8c952497dfa23c6bd 12077902 xbmc-bin_12.0~git20121119.22795bc-1_amd64.deb 5aa2ebacf4878c206ab7c5bac74d6ffe5597e9b736a72b8fe893b00dc8895377 58012 xbmc-eventclients-common_12.0~git20121119.22795bc-1_all.deb 32250ec6cf571dc65cdc25ff1c3d7a2a2c6cfb02077a96c5dfa277e824deb839 43332 xbmc-eventclients-dev_12.0~git20121119.22795bc-1_all.deb b1a54ea06e88a9f13e399ab082b693115bc18563ef50f1038a6cf67bd85f3ba4 61958 xbmc-eventclients-wiiremote_12.0~git20121119.22795bc-1_amd64.deb 44134bb33f740e3cdd1cea2f57ce3d2c27d0363edbb8e78997c8f935e194bc7f 36410 xbmc-eventclients-j2me_12.0~git20121119.22795bc-1_all.deb 151b1c66d1d5ffeb423ff36732e78b246a0e4a11cd2959d341b891b690d3ea6b 36834 xbmc-eventclients-ps3_12.0~git20121119.22795bc-1_all.deb 0d9b65033f992779bfe2983b9e59cd64fbcc8940750ee796d6c7c27574fb5a30 35654 xbmc-eventclients-xbmc-send_12.0~git20121119.22795bc-1_all.deb Files
Re: xbmc_12.0~git20121119.22795bc-1_amd64.changes ACCEPTED into experimental
On Mon, Nov 19, 2012 at 7:07 PM, Andres Mejia amejia...@gmail.com wrote: Hi all, FYI, I uploaded a new version of XBMC. I'm notifying you all because of a major change. This version of XBMC will be built and run using XBMC's internal copy of FFMpeg (the 10.2 branch of FFMpeg that is). Due to the number of changes done between FFMpeg and Libav (particularly with libavfilter), it would have taken an enormous amount of work to try and get XBMC building and running using Libav. Also, I did forget to note this major change in the changelog, but I did add a NEWS entry for this. Sorry about that. Also as an aside, I think we should discuss how to get ffmpeg back into Debian again. As I said some time ago, either Libav, FFMpeg, or both have to get their libraries and header paths renamed. I also want to note this now, apparently chromium has been using it's own internal copy of FFMpeg for some time now. Therefore, XBMC is not the first package where using an internal ffmpeg is being done. -- Forwarded message -- From: Debian FTP Masters ftpmas...@ftp-master.debian.org Date: Mon, Nov 19, 2012 at 6:49 PM Subject: xbmc_12.0~git20121119.22795bc-1_amd64.changes ACCEPTED into experimental To: Debian XBMC Packaging Team pkg-xbmc-maintain...@lists.alioth.debian.org, Andres Mejia ame...@debian.org Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 19 Nov 2012 17:56:50 -0500 Source: xbmc Binary: xbmc xbmc-bin xbmc-eventclients-common xbmc-eventclients-dev xbmc-eventclients-wiiremote xbmc-eventclients-j2me xbmc-eventclients-ps3 xbmc-eventclients-xbmc-send Architecture: source all amd64 Version: 2:12.0~git20121119.22795bc-1 Distribution: experimental Urgency: low Maintainer: Debian XBMC Packaging Team pkg-xbmc-maintain...@lists.alioth.debian.org Changed-By: Andres Mejia ame...@debian.org Description: xbmc - XBMC Media Center (arch-independent data package) xbmc-bin - XBMC Media Center (binary data package) xbmc-eventclients-common - XBMC Media Center (Event Client Common package) xbmc-eventclients-dev - XBMC Media Center (Event Client Dev package) xbmc-eventclients-j2me - XBMC Media Center (Event Client J2ME package) xbmc-eventclients-ps3 - XBMC Media Center (Event Client PS3 package) xbmc-eventclients-wiiremote - XBMC Media Center (Event Client WII Remote support package) xbmc-eventclients-xbmc-send - XBMC Media Center (Event Client XBMC-SEND package) Closes: 668901 681264 682312 685076 Changes: xbmc (2:12.0~git20121119.22795bc-1) experimental; urgency=low . * New upload for beta packages of XBMC Frodo. (Closes: #668901) (Closes: #681264) (Closes: #682312) * Recommends of python-qt3 is removed. (Closes: #685076) Checksums-Sha1: 8472b46a10e73a90c428bc6d328f3f7de38a97ea 3810 xbmc_12.0~git20121119.22795bc-1.dsc 938f168c780f803458cbda5eccfae1ec8860fbaf 54951931 xbmc_12.0~git20121119.22795bc.orig.tar.gz 3ad956b4addf812564d4c454b7028a2dbe7caf7e 37398 xbmc_12.0~git20121119.22795bc-1.debian.tar.gz dfd5c97e7ae3454af7f847fc26edf2f2082681db 21034010 xbmc_12.0~git20121119.22795bc-1_all.deb 4775e819446e436fba099b24eb6b577443a6af72 12077902 xbmc-bin_12.0~git20121119.22795bc-1_amd64.deb 81eefc8af233af513bd1714b5661f7cc3b5ab046 58012 xbmc-eventclients-common_12.0~git20121119.22795bc-1_all.deb e965b33bdc6fa6ff5b96859bcf4bf4844f682177 43332 xbmc-eventclients-dev_12.0~git20121119.22795bc-1_all.deb d81d331b436b68222d0774a6f4c1172389f600fb 61958 xbmc-eventclients-wiiremote_12.0~git20121119.22795bc-1_amd64.deb e620156fd4ae08b717a61bb4a2b807d18f902226 36410 xbmc-eventclients-j2me_12.0~git20121119.22795bc-1_all.deb 8eed3ec12c397346e544684a94b3e8abaa299613 36834 xbmc-eventclients-ps3_12.0~git20121119.22795bc-1_all.deb 11f4feae4ca1258edea2c13fd6f925efbb95a31a 35654 xbmc-eventclients-xbmc-send_12.0~git20121119.22795bc-1_all.deb Checksums-Sha256: 8a92846117224aea5e431abe73d8011b104528ab8cd54e40b3b6c6a199a1d4b4 3810 xbmc_12.0~git20121119.22795bc-1.dsc 777e5be318a901ec84914bb1029983d233ba615c7f6b71d8fd1191b7a5f83cb4 54951931 xbmc_12.0~git20121119.22795bc.orig.tar.gz 7cc5f5a2ed68ccbfb1660420f06372d1832bd56ed04ed31d03e5e2e5e1699ec0 37398 xbmc_12.0~git20121119.22795bc-1.debian.tar.gz ee3466c532549979154bc0aea70d047fafb49ad800e8358985dbc0bf63c14222 21034010 xbmc_12.0~git20121119.22795bc-1_all.deb d0502b10e7a7e9beb16e36929e86dd491fe7d62d6d70e6d8c952497dfa23c6bd 12077902 xbmc-bin_12.0~git20121119.22795bc-1_amd64.deb 5aa2ebacf4878c206ab7c5bac74d6ffe5597e9b736a72b8fe893b00dc8895377 58012 xbmc-eventclients-common_12.0~git20121119.22795bc-1_all.deb 32250ec6cf571dc65cdc25ff1c3d7a2a2c6cfb02077a96c5dfa277e824deb839 43332 xbmc-eventclients-dev_12.0~git20121119.22795bc-1_all.deb b1a54ea06e88a9f13e399ab082b693115bc18563ef50f1038a6cf67bd85f3ba4 61958 xbmc-eventclients-wiiremote_12.0~git20121119.22795bc-1_amd64.deb
Re: mjpegtools_2.0.0+debian-1_source+amd64.changes ACCEPTED into unstable, unstable
Wow, amazing! Good job guys! On Fri, Oct 12, 2012 at 6:38 PM, Reinhard Tartler siret...@gmail.com wrote: Well, that's just fine for experimental IMO Am 12.10.2012 18:02 schrieb Fabian Greffrath fab...@greffrath.com: Am Sonntag, den 07.10.2012, 11:13 -0700 schrieb Reinhard Tartler: Next steps: avidemux and transcode! Well, transcode is already in. ;) And avidemux does at least build and install cleanly with its own ffmpeg copy as of this evening. I have, however, given up to build it against the system libav libraries... - 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 -- ~ Andres ___ 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: [SCM] libav/master: Update libav-doc doc base. (Closes: #674139)
Note here that I'm updating the documentation package which will happen to fix this bug. I'm not going to start fixing issues with dmo. ~ Andres On May 23, 2012 10:31 AM, ceros-gu...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit cf1fbcb4af6757ef1208ea27d7f1ebb097890497 Author: Andres Mejia amejia...@gmail.com Date: Wed May 23 10:30:39 2012 -0400 Update libav-doc doc base. (Closes: #674139) diff --git a/debian/libav-doc.doc-base b/debian/libav-doc.doc-base index 014a90b..337f506 100644 --- a/debian/libav-doc.doc-base +++ b/debian/libav-doc.doc-base @@ -1,7 +1,7 @@ -Document: ffmpeg-doc -Title: ffmpeg API Documentation -Author: FFmpeg Developers -Abstract: This is the main documentation for the ffmpeg API. +Document: libav-doc +Title: Libav API Documentation +Author: Libav Developers +Abstract: This is the main documentation for the Libav API. Section: Programming Format: HTML -- Libav/FFmpeg packaging ___ pkg-multimedia-commits mailing list pkg-multimedia-comm...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-commits ___ 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: on package duplication between Debian and debian-multimedia
On Mon, May 14, 2012 at 10:14 AM, Reinhard Tartler siret...@gmail.com wrote: On Thu, May 10, 2012 at 2:23 PM, Stefano Zacchiroli lea...@debian.org wrote: Unless I'm mistaken, on April 7th, while the discussion between me and the pkg-multimedia-maintainer was going on, you've both renewed debian-multimedia.org for another year and registered the domain that now hosts http://www.deb-multimedia.org . I guess that is the website you want to move debian-multimedia.org to. You're right, that would solve the debian name problem. Frankly, this doesn't solve anything. First of all, deb-multimedia.org is confusingly similar to the former name, because only two letters are dropped. Moreover, the archive itself is still called 'debian-multimedia'. This means that users that use a mirror such as http://debian.informatik.uni-erlangen.de/debian-multimedia/ as advised remain confused. As shown earlier in this thread, such an URL does make people think this was an official Debian resource, which it is not. -- regards, 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 His website still shows Debian Multimedia in the header of all pages. Those need to be updated. Also, his website has no disclaimer (that I've seen) which states the site is not a part of or is affiliated with Debian. I know it wasn't explicitly mentioned before that he should post a disclaimer but, he should post a disclaimer on the front of his page and in his FAQ. Also, his donate page only says You can donate by using paypal in Euro/€. PayPal logo or directly to my bank account. account numbers In any case, thanks in advance. This is horrible IMO. This is practically the same kind of message sent via the spam I get every single day. How about showing a little appreciation when asking for contributions? This would work better Please consider offering a donation to help me cover the cost of maintaining this website/service. Your contributions are welcome. instructions on how to donate/who to contact/etc. And of course, his donate page definitely needs to be clear where/who the donations are going to (i.e. it needs a disclaimer making clear none of the donations go to Debian). -- ~ Andres ___ 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: Bug#672791: Strict internal dependencies make libavcodec53 uninstallable when updating to libav 0.9
On Sun, May 13, 2012 at 2:22 PM, Jonas Smedegaard d...@jones.dk wrote: On 12-05-13 at 07:48pm, Reinhard Tartler wrote: the 'old' libavcodec53, which a lot of applications link against, becomes uninstallable because of the strict internal dependencies: Depends: libavutil51 (= 4:0.8.1-0ubuntu1) | libavutil-extra-51 (= 4:0.8.1), libavutil51 ( 4:0.8.1-99) | libavutil-extra-51 ( 4:0.8.1.99) What can we do now about this: e) Use symbols files to resolve dependencies based on actual symbols used. I imagine private symbols from libav change frequently and it would be a pain trying to update symbol files for every release of libav because of this. I don't have any actual hard evidence for this however. I labelled this e) not d) as I suspect you _did_ think of this but don't like it (and/or I didn't understand how it is unsuitable here). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- ~ Andres ___ 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#672791: Strict internal dependencies make libavcodec53 uninstallable when updating to libav 0.9
On Sun, May 13, 2012 at 1:48 PM, Reinhard Tartler siret...@tauware.de wrote: Package: libavcodec53 Severity: important I have now prepared a new upstream snapshot of libav at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=shortlog;h=refs/heads/experimental. In this new version, the SONAME of libavcodec and libavformat was bumped from 53 to 54. This is not a problem by itself and necessary as a number of deprecated APIs have been dropped. However, libavutil51 has not been bumped, but is simply newer. This fact now causes the problem that the 'old' libavcodec53, which a lot of applications link against, becomes uninstallable because of the strict internal dependencies: Depends: libavutil51 (= 4:0.8.1-0ubuntu1) | libavutil-extra-51 (= 4:0.8.1), libavutil51 ( 4:0.8.1-99) | libavutil-extra-51 ( 4:0.8.1.99) What can we do now about this: a) We could simply drop the strict internal dependencies. They were mostly a safety guard to ensure that on upstream version upgrades, all shipped libraries stay in sync. This is exactly what breaks now. Technically, removing this safety net is easy to do by dropping a few lines in debian/rules. b) somehow ship a 'new' libavcodec53 that links against the new libavutil. Yay, code duplication. We would also need to duplicate libavformat53. I think this is a no-go. c) bump SONAME of libavutil This would work, but I'd rather not diverge from upstream's SONAMES. And convincing upstream to do this to accommodate Debian's rather strange decisions with strict internal dependencies is rather not going to happen. d) something else I didn't think of. TBH, I'd tend for option a), but before going that way, I'd also like to hear your input on that. Cheers, 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 I'm more inclined to go with option a) for those libraries/programs that do not need the strict internal dependencies (i.e. libraries and programs that are not using non-public headers and symbols). I think libavutil should drop the strict dependencies if this is the case. ~ Andres ___ 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#672791: Strict internal dependencies make libavcodec53 uninstallable when updating to libav 0.9
On Sun, May 13, 2012 at 3:10 PM, Reinhard Tartler siret...@tauware.de wrote: On So, Mai 13, 2012 at 20:43:08 (CEST), Andres Mejia wrote: On Sun, May 13, 2012 at 1:48 PM, Reinhard Tartler siret...@tauware.de wrote: Package: libavcodec53 Severity: important I have now prepared a new upstream snapshot of libav at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=shortlog;h=refs/heads/experimental. In this new version, the SONAME of libavcodec and libavformat was bumped from 53 to 54. This is not a problem by itself and necessary as a number of deprecated APIs have been dropped. However, libavutil51 has not been bumped, but is simply newer. This fact now causes the problem that the 'old' libavcodec53, which a lot of applications link against, becomes uninstallable because of the strict internal dependencies: Depends: libavutil51 (= 4:0.8.1-0ubuntu1) | libavutil-extra-51 (= 4:0.8.1), libavutil51 ( 4:0.8.1-99) | libavutil-extra-51 ( 4:0.8.1.99) What can we do now about this: a) We could simply drop the strict internal dependencies. They were mostly a safety guard to ensure that on upstream version upgrades, all shipped libraries stay in sync. This is exactly what breaks now. Technically, removing this safety net is easy to do by dropping a few lines in debian/rules. b) somehow ship a 'new' libavcodec53 that links against the new libavutil. Yay, code duplication. We would also need to duplicate libavformat53. I think this is a no-go. c) bump SONAME of libavutil This would work, but I'd rather not diverge from upstream's SONAMES. And convincing upstream to do this to accommodate Debian's rather strange decisions with strict internal dependencies is rather not going to happen. d) something else I didn't think of. TBH, I'd tend for option a), but before going that way, I'd also like to hear your input on that. [...] I'm more inclined to go with option a) for those libraries/programs that do not need the strict internal dependencies (i.e. libraries and programs that are not using non-public headers and symbols). I think libavutil should drop the strict dependencies if this is the case. Ah, so you suggest do have the strict internal dependencies excluded for libavcodec? For the sake of simplicity, I'd just drop them for all packages. I've introduced the strict internal dependencies in the days where there weren't proper releases, and the internal APIs were much more in flux. I think this has vastly improved in the mean time. Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 If libavcodec is not using any private headers or symbols from any of the other libraries, then yes, the strict internal dependencies should be excluded. -- ~ Andres ___ 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: Decent DVD rippers?
On Sun, May 13, 2012 at 5:19 PM, Fabian Greffrath fab...@greffrath.com wrote: Am Freitag, den 11.05.2012, 16:10 -0400 schrieb Andres Mejia: Could it use vo-aacenc as an alternate? I've never considered. It's not like vo-aacenc is a drop-in replacement for faac, their APIs appear quite dissimilar (IIRC vo-aacenc is C++ while libfaac is C). Yes it's not a drop-in replacement and I believe faac has some features not available in vo-aacenc. I could be mistaken about the features however. It probably makes more sense to replace use of libmp4v2 with libav instead anyway. mp4v2 upstream doesn't look very active IMO and it may serve the handbrake project better to switch to something else. There is still atomicparsley as an alternative. The gtkpod mainatiners have just turned it into a GPL'ed library, cf. http://old.nabble.com/Finally-pushed-alternative-to-libmp4v2-td33723081.html - Fabian Ok, saving this little information about atomicparsley in the ITP bug for handbrake. -- ~ Andres ___ 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: [SCM] handbrake packaging branch, master, created. de1f9ddeef0932713c9d436d3ce28db14ebe9b39
On Sun, May 13, 2012 at 5:27 PM, Fabian Greffrath fab...@greffrath.com wrote: Am Samstag, den 12.05.2012, 11:29 -0400 schrieb Andres Mejia: I just glanced over the changes to this. To be on the safer side, the symbols needed by handbrake and provided in audioconvert.c should be built from handbrake. This way, any internal changes made to libav for audioconvert won't break handbrake. IIRC, the only symbol from audioconvert.h that was actually needed was struct AVAudioConvert, so I declared that myself and was ready with it. Please compare with my patch from http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-February/024218.html: --- handbrake-0.9.5.orig/libhb/decavcodec.c +++ handbrake-0.9.5/libhb/decavcodec.c @@ -62,7 +62,9 @@ #include hb.h #include hbffmpeg.h #include downmix.h -#include libavcodec/audioconvert.h +//#include libavcodec/audioconvert.h +struct AVAudioConvert; +typedef struct AVAudioConvert AVAudioConvert; static int decavcodecInit( hb_work_object_t *, hb_job_t * ); static int decavcodecWork( hb_work_object_t *, hb_buffer_t **, hb_buffer_t ** ); I prefer this patch. It's better than including all of audioconvert.h. Would you mind modifying handbrake packaging to use this patch instead? -- ~ Andres ___ 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: Bug#672791: Strict internal dependencies make libavcodec53 uninstallable when updating to libav 0.9
On Sun, May 13, 2012 at 5:21 PM, Fabian Greffrath fab...@greffrath.com wrote: Am Sonntag, den 13.05.2012, 19:48 +0200 schrieb Reinhard Tartler: a) We could simply drop the strict internal dependencies. They served as a nice shelter against package mixture wth d-m.o packages in the past. But if they stand in the way for our own development from now on, kill them! - Fabian +1 to this. I think we all tried to work with Christian at some point and ultimately, Christian would just rather do his own thing. He's even switching his site to deb-multimedia.org. At this point, I'm not concerned what affect any change we make does to those using dmo. If there's some bug related to using dmo, it's up to Christian to fix it. With that said, we shouldn't keep these strict internal dependencies for the sake of dealing with issues from dmo. -- ~ Andres ___ 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#672561: libavcodec-dev: Missing /usr/include/libavcodec/audioconvert.h
On Sat, May 12, 2012 at 1:39 AM, Rogério Brito rbr...@ime.usp.br wrote:
Package: libavcodec-dev
Severity: important
Hi.
The libavcodec-dev package is missing
/usr/include/libavcodec/audioconvert.h.
Audioconvert is not a public header in either libav or ffmpeg. What is
suppose to be used for this functionality is libavresample or
libswresample.
This file is needed by handbrake. If I clone the libav git tree,
checkout the v0.8.2 tag and copy that file to /usr/include/avcodec,
then I am able to successfully compile handbrake with Debian's libav,
without needing to download things from outside.
BTW, regarding handbrake, I am down to few packages now that need to
be taken from outside debian for it to compile, namely:
* MODULES += contrib/libdvdread
* MODULES += contrib/libdvdnav
* MODULES += contrib/mpeg2dec
Does handbrake used patched versions of these libs or can it use these
libs as released upstream?
Everything else works with packages in Debian *or* with packages in
the pkg-multimedia git repositories (e.g., libmkv, faac, libmp4v2).
Ping Fabian. Was libmkv ready for upload?
Could vo-aacenc be used instead of faac? Also, as I mentioned in
another email, libmp4v2 should be replaced with libav. mp4v2 is seeing
less and less development and it's probably better to look into
replacing use of mp4v2 anyway.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Also next time, please leave out things unrelated to a bug in it's bug report.
--
~ Andres
___
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: Bug#672561: libavcodec-dev: Missing /usr/include/libavcodec/audioconvert.h
On May 12, 2012 2:22 AM, Rogério Brito rbr...@ime.usp.br wrote:
Hi there.
On Sat, May 12, 2012 at 3:07 AM, Andres Mejia amejia...@gmail.com wrote:
On Sat, May 12, 2012 at 1:39 AM, Rogério Brito rbr...@ime.usp.br
wrote:
Package: libavcodec-dev
Severity: important
Hi.
The libavcodec-dev package is missing
/usr/include/libavcodec/audioconvert.h.
Audioconvert is not a public header in either libav or ffmpeg. What is
suppose to be used for this functionality is libavresample or
libswresample.
I'm just getting it to compile, at first, and they use that. They
probably need a cluebat, then, if that is not a public interface. The
problem here is that they use AVAudioConvert, which is present only in
that header.
I'm not exactly sure if I want to patch this so heavily as to fix the
use of that interface.
This file is needed by handbrake. If I clone the libav git tree,
checkout the v0.8.2 tag and copy that file to /usr/include/avcodec,
then I am able to successfully compile handbrake with Debian's libav,
without needing to download things from outside.
BTW, regarding handbrake, I am down to few packages now that need to
be taken from outside debian for it to compile, namely:
* MODULES += contrib/libdvdread
* MODULES += contrib/libdvdnav
* MODULES += contrib/mpeg2dec
Does handbrake used patched versions of these libs or can it use these
libs as released upstream?
I have yet to see which patches can be dropped and which don't. OTOH,
the basics compile and a brief test here works. :)
Everything else works with packages in Debian *or* with packages in
the pkg-multimedia git repositories (e.g., libmkv, faac, libmp4v2).
Ping Fabian. Was libmkv ready for upload?
I think it is fine as is. Not sure if the legal stuff
(debian/copyright etc.) is all in place for an upload to unstable.
Could vo-aacenc be used instead of faac?
I still have to study that to see what can be done and how similar the
interfaces are.
Also, as I mentioned in another email, libmp4v2 should be replaced with
libav. mp4v2 is seeing
less and less development and it's probably better to look into
replacing use of mp4v2 anyway.
That's the same story as with vo-aacenc/faac.
Also next time, please leave out things unrelated to a bug in it's bug
report.
OK, but the excitement is really huge and I couldn't help sending some
side comments. :) Feel free to reply to the bug only the parts
pertaining to the bug and to the mailing list the other parts (please,
keep me CCed).
Thanks.
P.S.: Now, it compiles with Debian's mpeg2, which is one fewer embedded
library.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Keep up the great work. You may also want to create an ITP bug for
handbrake now.
~ Andres
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
ITP: handbrake -- Rips and encodes DVDs
owner 456165 pkg-multimedia-maintainers@lists.alioth.debian.org retitle 456165 ITP: handbrake -- Rips and encodes DVDs stop The package is now being worked on. See [1]. 1. http://anonscm.debian.org/gitweb/?p=pkg-multimedia/handbrake.git ___ 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: [SCM] handbrake packaging branch, master, created. de1f9ddeef0932713c9d436d3ce28db14ebe9b39
On Sat, May 12, 2012 at 4:58 AM, rbrito-gu...@users.alioth.debian.org wrote:
The branch, master has been created
at de1f9ddeef0932713c9d436d3ce28db14ebe9b39 (commit)
- Shortlog
commit de1f9ddeef0932713c9d436d3ce28db14ebe9b39
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 05:43:47 2012 -0300
LinGUI: Allow user to pass libavcodec settings also with MPEG4 video.
In the present, if the user chooses the video codec to be MPEG2, then he
can
pass advanced options to libavcodec, but no advanced options are possible
if MPEG4 is selected.
This patch fixes it.
I sent a pull request to [the HandBrake maintainers' github account][0] and
[they applied it][1], but have not given me credit for it. :(
[0]: https://github.com/HandBrake/HandBrake/pull/9
[1]:
https://github.com/HandBrake/HandBrake/commit/6bfa70d2543a5defd582236d7ecc2e38d2675bdf
Signed-off-by: Rogério Brito rbr...@ime.usp.br
commit 046c3c7ba79f5c6c6e83ab7a386defec1a10c570
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 05:41:14 2012 -0300
Update the changelog.
Git-Dch: Ignore
commit 8500dce1b63f3b53e539fbd7f26acef4fb8b984b
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 05:34:21 2012 -0300
Force handbrake to link against the system's libav.
Note that here we use a very dirty hack, namely, taking the file
`audioconvert.h` from libav's git tree (which I was told is not a public
interface), and putting it `libhb` directory.
We also pass the `/usr/include/libavcodec` directory as an include dir for
the other headers of libav to be found.
I just glanced over the changes to this. To be on the safer side, the
symbols needed by handbrake and provided in audioconvert.c should be
built from handbrake. This way, any internal changes made to libav for
audioconvert won't break handbrake.
Of course, it's better to switch to libavresample for this than to use
this hack.
commit af05fe0f71041ab4bd5959c89df0943e3c2e9057
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 04:28:16 2012 -0300
debian/patches: Remove patching of ffmpeg on kFreeBSD.
The rest of the patch should be forwarded upstream, if it is not yet in
their tree.
commit 8811efedad28e25e74ea93e3ae74941f7e26e539
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 04:24:55 2012 -0300
debian/patches: Don't bother with PowerPC compilation of mpeg2dec.
We are not building `mpeg2dec` and, if necessary, the other parts of the
patch can be appropriately forwarded to the packager or upstream.
Note that it may be possible to work around the necessity of mpeg2dec by
passing the option `--enable-ff-mpeg2` to the main configure script.
I have not yet investigated this possibility.
commit 47a05ab838d06447fb33d88457cbf1fd1bca1eb3
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 04:21:43 2012 -0300
debian/patches: Remove part to set compiler for ffmpeg.
There's no need for patching this further, as we don't use ffmpeg.
commit 651649036e56df6cc946186a45367d952fa0ea58
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 04:18:23 2012 -0300
debian/patches: Disable 04_format-security.diff from being applied.
We are not compiling ffmpeg here, and this should be taken care of in
Debian's libav package instead, if needed.
commit da0a3c9fd9ba4455d508e46bbafbecb135007347
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 04:10:24 2012 -0300
debian/control: Add Reinhard Tartler to Uploaders.
commit 36947cc69e22f196eab6a1c7d2890ba036ad4d71
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 03:58:17 2012 -0300
debian/rules: Install upstream's changelog.
commit 15b0baaf4c3ad71c1f7a9ea0b2df39e51dc34aab
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 03:49:56 2012 -0300
debian/patches: Remove encoding indication from desktop file.
commit 671ba17089e281b402aa5c8094b616ae1844e464
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 03:47:05 2012 -0300
Update the changelog.
Git-Dch: Ignore
commit 04a0696f79b9ad0ceb622d08518a71f48b811a54
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 03:44:57 2012 -0300
debian/control: Change maintainer and add me as uploader.
commit 7159973e64358087cc67e4c8ff9b15a7e796b9ec
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 03:43:36 2012 -0300
debian/control: Remove libdvd{read,nav}-dev from build deps for the moment.
commit 69a9980a773b4ac6ada70c0d7408e81768b339c7
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 03:09:53 2012 -0300
Refresh debian/patches/01_build.diff
commit bd52d6cd9afdbbe4d8e2b4ce2777889ab82dcfaa
Author: Rogério Brito rbr...@ime.usp.br
Date: Sat May 12 02:56:02 2012 -0300
debian/control: One fewer external library/package: mpeg2.
Drop
Re: ITP: handbrake -- Rips and encodes DVDs (was Bug#672561: libavcodec-dev: Missing /usr/include/libavcodec/audioconvert.h)
On Sat, May 12, 2012 at 5:07 AM, Rogério Brito rbr...@ime.usp.br wrote:
Hi, all.
On Sat, May 12, 2012 at 3:46 AM, Reinhard Tartler siret...@gmail.com wrote:
The problem with that is that audioconvert.h is not part of the public
API. Moreover, most of the APIs have already been removed in current
libav/master in favor of the newly introduced libavresample library.
Therefore, I do not think it would be a good idea to start shipping
this header.
OK.
The proper long-term solution is to port handbrake to 'libavresample'
(not yet uploaded to experimental, the packaging needs review, and is
not going to be included in wheezy). As short-term workaround, I'd
suggest to copy the parts of audioconvert.h and audioconvert.c to the
handbrake packaging.
For the quick and dirty solution, I did just that, but the packaging
is crufty. As I need to get some sleep right now, it will be great to
see the package gain some love from others, even if we can't upload
handbrake due to licensing and dependencies in time for wheezy.
OTOH, it never hurts to be able to have the package in source form
ready for a compilation to be used as we see fit, while the package
has not hit the main archive.
That's excellent news! Thanks for working on it and count me in as
supporter (i.e., put me to Uploaders).
Just did that and pushed my current changes to the repo:
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/handbrake.git
I hope that others will join me in getting it slowly in shape.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
I just noticed that libmkv was written specifically for handbrake. In
this case, I wouldn't even bother uploading libmkv separately and just
use whatever libmkv ships with handbrake.
--
~ Andres
___
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#672659: ITP: libmkv -- Alternative to the official libmatroska/libebml libraries
Package: wnpp Severity: wishlist Owner: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org * Package name: libmkv Version : 0.6.5.1 Upstream Author : saint...@gmail.com * URL : https://github.com/saintdev/libmkv * License : GPLv2+ Programming Lang: C Description : Alternative to the official libmatroska/libebml libraries This library is meant to be an alternative to the official libmatroska library. It is writen (Thanks Haali) in plain C, and intended to be very portable. ___ 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: ITP: handbrake -- Rips and encodes DVDs (was Bug#672561: libavcodec-dev: Missing /usr/include/libavcodec/audioconvert.h)
On Sat, May 12, 2012 at 1:36 PM, Reinhard Tartler siret...@gmail.com wrote: On Sat, May 12, 2012 at 5:40 PM, Andres Mejia amejia...@gmail.com wrote: I just noticed that libmkv was written specifically for handbrake. In this case, I wouldn't even bother uploading libmkv separately and just use whatever libmkv ships with handbrake. TBH, I agree. Fabian, this does not mean that your work on git+ssh://git.debian.org/git/pkg-multimedia/libmkv was in vain. As soon as some other package uses it, we can use your packaging and upload to debian. But until then, we gain little to nothing by shipping it outside of handbrake -- regards, Reinhard I was going off by the assumption that handbrake ships with libmkv, but I found it doesn't. It simply downloads libmkv. I think it will be easier to upload libmkv instead. -- ~ Andres ___ 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: Decent DVD rippers?
Late posting but... On Thu, Feb 2, 2012 at 4:03 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 01.02.2012 18:19, schrieb Reinhard Tartler: Feel free to push what you currently have to git.debian.org, I might find some time next week to have a closer look. Maybe we can get it to use opencore-aac instead. What I have at the moment is absolutely unrepresentable. It is based on Marillat's package with some changes to patches and some out-of-patch changes. Maybe I'll try to break out my own changes as a separate patch once I got it to compile and post it here. Some observations: - Just as avidemux (or maybe even worse) handbrake downloads static source snapshots of external libraries, patches them and builds static libraries. - It uses lots of deprecated ffmpeg API and even patches its private copy to export a private header. It's only needed for one declaration, so that's easily patched out. - It uses a private copy of libdca and patches it to use different names for its structs, WTF. However, this is also easily solved with a typedef. - It uses libmkv, which is currently not in Debian. I rebuilt the Marilat package for the time being, but this package should be no problem. - It uses an ancient snapshot of libbluray that has a slightly different API than the version in Debian. - It uses faac which is considered non-free and thus not in Debian. Could it use vo-aacenc as an alternate? - Last but not least, it uses libmp4v2. Apart from the fact that there have also been slight APi changes compared to the version in Debian, this library is licensed under the MPL. AFAICT this and the GPL are incompatible, so the resulting software is unredistributable. It probably makes more sense to replace use of libmp4v2 with libav instead anyway. mp4v2 upstream doesn't look very active IMO and it may serve the handbrake project better to switch to something else. If the latter turns out to be true, I see no change for handbrake to enter Debian and thus no sense in working on it anymore. - 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 -- ~ Andres ___ 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: Initial packaging of handbrake for Debian (WIP)
On Fri, May 11, 2012 at 2:35 PM, Fabian Greffrath fab...@greffrath.com wrote: Dear Rogerio, As I am a brand new dad, I want to transcode videos of my newborn son to formats that other family members can see and the first thought of mine was to do the job with handbrake. First of all, congratulations to you new-born child! Yes, congratz! Would you be interested in the work that I have done so far? Please, keep in mind that it is *incomplete* and very *dirty*, but a start, at least. :) I have once - not that long ago, actually - myself tried to get it built cleanly. But I failed and finally gave up for the reasons described in this post and the one following it: http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-February/024217.html I wish you better luck and patience. ;) However, please feel free to open a GIT repo for it and share your work with us! Yes, feel free to push your work to the git repos. - 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 -- ~ Andres ___ 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#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)
On May 4, 2012 4:43 PM, Fabian Greffrath fab...@greffrath.com wrote: libav - x264 - libav AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared library. So theortically (!) this issue could be solved by two separate source packages for the x264 frontend and the library. - Fabian This doesn't resolve the issue with opencv though. ~ Andres ___ 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#671302: libav: circular dependency between libav and opencv
On Thu, May 3, 2012 at 3:44 AM, Pino Toscano p...@debian.org wrote: Package: libav Version: 6:0.8.1-7 Severity: important Hi, libav 6:0.8.1-7 reenables the use of opencv... which itself uses libav libraries. This currently makes libav unbuildable on mipsel and hurd-i386, and generically makes libav no more bootstrap'able without having itself compiled already. Could you please drop the opencv usage again, please? Thanks, -- Pino ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers What could be done instead is a binary only upload with opencv support disabled (i.e. use dpkg-buildpackage -B). Doing it on our end will not require changing the version. Once this package is uploaded, the release team can then be asked to do a binNMU for these archs, which will bring back opencv support since the archive will contain the regular *.debian.tar.gz changes that included opencv. I believe this is better than doing a full build on all archs without opencv, then doing another build with opencv. -- ~ Andres ___ 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: debian-multimedia.org considered harmful - redux
On May 3, 2012 9:24 AM, Stefano Zacchiroli lea...@debian.org wrote:
On Thu, Apr 12, 2012 at 02:26:27PM +0200, Stefano Zacchiroli wrote:
I've drafted a message that I'd like to send to Christian publicly
Cc:-ing this list. It is attached to this mail for review by the
pkg-multimedia team. (Yes, I know this is a public list and Christian
will likely read it before the review, but I don't particularly mind: it
will just anticipate a public discussion we'd like to have anyhow.)
I'd appreciate your feedback on it.
I've now patched my first draft trying to take into account your
feedback without changing the substance of the message I think we should
send through. The new draft is attached.
You're feedback is, again, very welcome.
If you have no further changes to suggest or objections, I can send it
this week-end.
Either way, please let me know,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
-- Forwarded message --
From: Stefano Zacchiroli lea...@debian.org
To: Christian Marillat maril...@debian.org, maril...@free.fr
Cc: pkg-multimedia-maintainers@lists.alioth.debian.org
Date: Thu, 3 May 2012 15:22:49 +0200
Subject: on package duplication between Debian and debian-multimedia
Dear Christian,
as you probably are aware of, there are recurring discussions on the
package duplication between the official Debian archive and the
debian-multimedia.org (d-m.o from now on) that you maintain.
AFAIK, the Debian team in charge of maintaining multimedia packages
(that I'm Cc:-ing) is not happy about the duplication and has approached
you about that [1], providing some evidence of the troubles that it
causes to them and to Debian users that also happen to use d-m.o. OTOH
I'm sure you are maintaining d-m.o to provide a useful service to Debian
users, when some of the packages you distribute are not available in
Debian proper.
[1]
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-March/025498.html
Personally, I think that principle is fine, but I'm worried about the
duplication part. Not only due to the troubles that it might cause to
users, but also for the apparent waste of maintenance energies. Energies
that could be put into better use if you and the pkg-multimedia team
could find a way to collaborate, and to do so contributing to the
*official* Debian packaging of the concerned software.
I have no specific opinion on the technical claims that d-m.o causes
trouble to official Debian packages. That might be true or not. Ditto
for your allegations of conflict of interest in the maintenance of
ffmpeg or libav in Debian. But I observe that *in* Debian we do have
mechanisms to solve that kind of issues, if and when they arise. As long
as you keep on doing your work outside Debian instead of raising your
concerns within Debian, we'll have to keep on assuming that what is
being done in Debian is fine and is entitled to the official status that
come with the name Debian.
Thinking about it, I think we should choose one of the two possible way
forward:
1) You and the pkg-multimedia team reach an agreement on
which-packages-belong-where. One way to settle would be that for
every package that exist in the official Debian archive, the same
package should not exist in d-m.o, unless it has a version that does
not interfere with the official packages in standard Debian
installations. Another way would be to rename packages and sonames.
I understand that such agreements would give a sort of advantage to
the pkg-multimedia people over d-m.o, but that seems to be warranted
by the fact that they are doing the official packaging, while you're
not. If, as I hope, you could start doing your packaging work
(wherever possible) within Debian as well, things would be different
and we could consider solving potential technical conflicts in the
usual Debian way.
2) You stop using debian as part of the domain name of your
repository, which is confusing for users (e.g. [2,3]). That would
allow each part to keep on doing what they want in terms of
packaging, but at least would remove any of the existings doubts
about the official status of d-m.o.
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660924#20
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668308#47
I can imagine that would be a painful step for you to take, given the
well established domain name. But it seems fair to ask you to do so
if we couldn't manage to find an agreement between you and the
official Debian packaging initiative of software you're maintaining
in an unofficial repository.
We could also consider various in-between solutions,
Bug#671302: libav: circular dependency between libav and opencv
On May 3, 2012 9:30 AM, Pino Toscano p...@debian.org wrote: Alle giovedì 3 maggio 2012, Andres Mejia ha scritto: On Thu, May 3, 2012 at 3:44 AM, Pino Toscano p...@debian.org wrote: Package: libav Version: 6:0.8.1-7 Severity: important Hi, libav 6:0.8.1-7 reenables the use of opencv... which itself uses libav libraries. This currently makes libav unbuildable on mipsel and hurd-i386, and generically makes libav no more bootstrap'able without having itself compiled already. Could you please drop the opencv usage again, please? What could be done instead is a binary only upload with opencv support disabled (i.e. use dpkg-buildpackage -B). Doing it on our end will not require changing the version. Once this package is uploaded, the release team can then be asked to do a binNMU for these archs, which will bring back opencv support since the archive will contain the regular *.debian.tar.gz changes that included opencv. I believe this is better than doing a full build on all archs without opencv, then doing another build with opencv. This mess (which is only a mess, not a clean solution) does not solve at all the fact that you cannot do a clean build of libav without having libav compiled already (for opencv). I don't see this as a viable solution, especially if in the future the epoch is raised bringing again conflicts between the old libav libraries and the new one. -- Pino Toscano I'm not entirely certain how build circular dependency issues like this are resolved. Perhaps we should ask for help from the toolchain package maintainers or debian-devel. ~ Andres ___ 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#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)
On May 3, 2012 10:20 AM, Andres Mejia amejia...@gmail.com wrote: On May 3, 2012 9:30 AM, Pino Toscano p...@debian.org wrote: Alle giovedì 3 maggio 2012, Andres Mejia ha scritto: On Thu, May 3, 2012 at 3:44 AM, Pino Toscano p...@debian.org wrote: Package: libav Version: 6:0.8.1-7 Severity: important Hi, libav 6:0.8.1-7 reenables the use of opencv... which itself uses libav libraries. This currently makes libav unbuildable on mipsel and hurd-i386, and generically makes libav no more bootstrap'able without having itself compiled already. Could you please drop the opencv usage again, please? What could be done instead is a binary only upload with opencv support disabled (i.e. use dpkg-buildpackage -B). Doing it on our end will not require changing the version. Once this package is uploaded, the release team can then be asked to do a binNMU for these archs, which will bring back opencv support since the archive will contain the regular *.debian.tar.gz changes that included opencv. I believe this is better than doing a full build on all archs without opencv, then doing another build with opencv. This mess (which is only a mess, not a clean solution) does not solve at all the fact that you cannot do a clean build of libav without having libav compiled already (for opencv). I don't see this as a viable solution, especially if in the future the epoch is raised bringing again conflicts between the old libav libraries and the new one. -- Pino Toscano I'm not entirely certain how build circular dependency issues like this are resolved. Perhaps we should ask for help from the toolchain package maintainers or debian-devel. ~ Andres Hello all, I would like to know if there is a good (perhaps best) approach in resolving issues with packages with circular build dependencies. Libav has various circular build dependencies including. libav - opencv - libav libav - x264 - libav libav - x264 - gpac - libav I found some mention of this issue at [1]. This however doesn't offer any clear solution. 1. http://wiki.debian.org/DebianBootstrap ~ Andres ___ 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: Bug#670861: libavcodec53: unsatisfiable dependencies on libavutil51
On Sun, Apr 29, 2012 at 2:38 PM, Sven Joachim svenj...@gmx.de wrote: Package: libavcodec53 Version: 6:0.8.1-5 Severity: grave Your package is not installable, because it depends on both libavutil51 (= 6:0.8.1-5) and libavutil51 ( 5:0.8.1-99) which cannot possibly be both fulfilled. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.4.0-rc4-nouveau+ (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers Offtopic here but, I want to make sure we do not have anymore bugs like this in the next release of Debian after wheezy. I am for having only one libavcodec library that is GPLv3+ enabled. I don't have specific stats but I imagine packages that cannot go with a GPLv3+ enabled libav are few and are simply other (L)GPL packages. In such a case, these packages should just be relicensed (LGPLv2.1+ or GPLv2+ should be fine). A more extreme measure is that these packages are simply dropped, but if that what it takes to stop this kind of bug, I rather have the packages dropped. -- ~ Andres ___ 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: Helping with Maintenance of Packages in Debian
On Fri, Apr 27, 2012 at 9:18 PM, Hans-Christoph Steiner h...@at.or.at wrote: On Apr 27, 2012, at 7:21 AM, Fabian Greffrath wrote: Am 26.04.2012 18:18, schrieb Hans-Christoph Steiner: When I read statements like Uploading ffmpeg would be a bad idea, it seems to me that the Debian-multimedia team has taken sides on the ffmpeg-libav fork dispute. That is not a position that a Debian team should take. Both ffmpeg and libav remain valuable free software that people want to use. And if someone is willing to do the work, Debian and Debian Multimedia should welcome both ffmpeg and libav. I disagree and second Andres' statement that uploading ffmpeg into Debian *now* in its current state is a bad idea. This is not because ffmpeg is bad per se - it isn't - it's just that we decided to go the libav route. This switch is not irrevocable, but so far no general problems have occured with libav and I think it fits better to Debian's release model. There is simply no pressing reason to switch back. We do not disagree at all on this point. I'm not saying that we should just upload ffmpeg as is, obviously it would be stupid to upload ffmpeg if it broke things. But we should welcome anyone who wants to do the work to make it possible to install libav and ffmpeg at the same time, or any other reasonable solution. And since this is a very political issue, we do need to speak carefully and clearly. That's why I object to the statement Uploading ffmpeg would be a bad idea. It is very broad, and wrong from some legitimate Debian-specific points of view. To install libav and ffmpeg at the same time, you have to either make them ABI compatible or have the libraries, headers, programs, and anything else that conflicts renamed. I am for this only if you work with (or anyone works with) the two upstreams. I am against this if it's to remain Debian-specific changes. I rather not resort to forking both projects, plus I don't want another situation similar to the SSL/SSH keys issues from the past [1]. Furthermore, currently libav and ffmpeg share the same library name space without being binary compatible - they are just not drop-in replacements for each other. This is also the reason for most of the bug reports we receive from users, who mixed up Debian packages built against libav with ffmpeg libraries from d-m.o. From what I know, this really seems to me a question for libav itself. IMHO, it is a version of the code with a new name, so that seems that the burden falls on libav to do it. And for the record, I have zero interest in getting involved in the politics, and I don't even want to know what happened to cause the libav fork. I am just offering a Debian user's perspective on two pieces of valuable software that have some technical conflicts. Renaming of anything is up to the upstream projects, not Debian. If we would re-introduce ffmpeg into Debian now, alongside libav, we'd have two choices. Either we get ffmpeg and libav binary-compatible and sustain this compatibility for all subsequent releases. Or we can live with the incompatibility, but then we sould have to rename the libraries of one of the projects and have to build each and every depending package twice, once against libav and once against ffmpeg - with appropriate package dependency declarations and migration plans. Do you think any of these alternatives is worth the effort? I don't! I'm specifically interested in the ffmpeg command line util, I don't really need all the libraries. That wouldn't be hard to package. As for libraries, how about putting the ffmpeg versions into /usr/include/ffmpeg and /usr/lib/ffmpeg? Then if someone wants to build against them, they can add -I/usr/include/ffmpeg and -L/usr/lib/ffmpeg. For most projects that use the libav* libraries, there probably wouldn't be any difference between using the ffmpeg or libav versions, so it would be silly to make all packages for both. libav already builds and provides the ffmpeg package. This is done despite it being removed in libav upstream. It's only provided in Debian for backward compatibility and to ease migration to avconv. The plan is to remove ffmpeg after the next release is out. As for the suggestions in library and header placements for ffmpeg, you're essentially asking for ffmpeg to be renamed. In this case, like I said already, you need to work with upstream. And of course, I'm not telling anyone that they should do the work here. I am saying we should welcome anyone who wants to do it. Oops, I guess I already said that ;) .hc All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne 1.
Re: Helping with Maintenance of Packages in Debian
On Sat, Apr 28, 2012 at 9:32 PM, Hans-Christoph Steiner h...@at.or.at wrote: On Apr 28, 2012, at 3:25 AM, Reinhard Tartler wrote: On Sat, Apr 28, 2012 at 3:08 AM, Hans-Christoph Steiner h...@at.or.at wrote: On Apr 26, 2012, at 3:31 PM, Reinhard Tartler wrote: On Thu, Apr 26, 2012 at 6:18 PM, Hans-Christoph Steiner h...@at.or.at wrote: ffmpeg provides many things that libav does not. For example, I have written an audio redaction plugin for ffmpeg. Such a plugin is not possible in libav. Please elaborate. What makes this impossible. Maybe you can point to your plugin? From what I can tell, they improved the audio plugin API in ffmpeg 0.9 quite a bit. When I was programming my plugin, I looked at both libav and ffmpeg. It wasn't until I looked at ffmpeg 0.9 that it seemed feasible. I attached my plugin source code: Oh, you're talking about libavfilter. Well, so far there is not a single application in debian that uses it, so it clearly wasn't a priority for me. It is true that lavfi has more functionality in ffmpeg, espc. since stefano has implemented his audio filtering work only after the split. On the libav side, I'd suggest talking to anton about this. He is very open and helpful, so why don't you try to catch him on irc, show him the plugin source code and see if he can port it to libav's libavfilter? Ahem, XBMC uses libavfilter. XBMC would like to have buffersink filter merged into libav. We would also like all the other new changes in libavfilter merged into libav as well (wherever possible). See [1] on what it's like to support both libav and ffmpeg. I already mentioned this in #libav-devel and was told Anton is working on it. Not trolling here, just saying. There is indeed at least one application that does use libavfilter, and that is the ffmpeg command line tool. I think that's how most people use the functions in libavfilter. There are going to be differences between ffmpeg and there are going to solid reasons to use one or the other. So it seems futile to me to ask the devs to make them the same thing when the devs just split up over that very issue. I should add, since this came up in the discussion related to debian-multimedia.org, that this discussion about ffmpeg and libav should not be taken to mean that I am arguing against the proposals related to debian-multimedia.org. I have also been burned by debian-multimedia.org package conflicts, and at the same time I think that the debian-multimedia.org packages are a valuable resource. I think it is a good idea to make debian-multimedia.org more distinct from Debian itself, and also, it is a good idea to try to get as much of the debian-multimedia.org packages into Debian as possible. So I support the DPL's statement on that specific topic. .hc [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers 1. https://github.com/xbmc/xbmc/pull/629/files -- ~ Andres ___ 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#660786: closed by Andres Mejia amejia...@gmail.com (Re: Bug#660786: ffmpeg: please migrate /etc/ffserver.conf to /etc/avserver.conf)
reopen 660786 severity 660786 minor thanks On Apr 23, 2012 4:42 AM, Luca Capello l...@pca.it wrote: notfixed 660786 4:0.8.1-1 thanks Hi there! On Sun, 22 Apr 2012 17:39:13 +0200, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the ffmpeg package: #660786: ffmpeg: please migrate /etc/ffserver.conf to /etc/avserver.conf It has been closed by Andres Mejia amejia...@gmail.com. [...] From: Andres Mejia amejia...@gmail.com Subject: Re: Bug#660786: ffmpeg: please migrate /etc/ffserver.conf to /etc/avserver.conf To: 660786-d...@bugs.debian.org, cont...@bugs.debian.org Date: Sun, 22 Apr 2012 11:36:29 -0400 fixed 660786 4:0.8.1-1 stop [...] This has since been fixed in version 4:0.8.1-1. No, it is not: = root@gismo:/etc# ls -l /etc/ffserver.conf /etc/avserver.conf -rw-r--r-- 1 root root 9085 Feb 5 23:43 /etc/avserver.conf -rw-r--r-- 1 root root 9085 Sep 1 2011 /etc/ffserver.conf root@gismo:/etc# dpkg-query -W ffmpeg ffmpeg 5:0.8.1-4 root@gismo:/etc# dpkg-query -W libav\* libav-tools 5:0.8.1-4 libavahi-client3:amd64 0.6.31-1 libavahi-common-data:amd64 0.6.31-1 libavahi-common3:amd64 0.6.31-1 libavahi-core7:amd640.6.31-1 libavahi-glib1:amd640.6.31-1 libavcodec-extra-53 libavcodec53:amd64 5:0.8.1-4 libavdevice-extra-53 libavdevice53:amd64 5:0.8.1-4 libavfilter-extra-2 libavfilter2:amd64 5:0.8.1-4 libavformat-extra-53 libavformat53:amd64 5:0.8.1-4 libavutil-extra-51 libavutil51:amd64 5:0.8.1-4 root@gismo:/etc# = And 4:0.8.1-1 debian/changelog does not contain any hint about this issue. Thx, bye, Gismo / Luca ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers I suppose what you want is a proper migration for the renamed config file. This would only affect users who have modified /etc/ffserver.conf before. I'll look into this. ~ Andres ___ 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: Usertags for dmo
On Sun, Apr 22, 2012 at 1:03 PM, Andres Mejia amejia...@gmail.com wrote: Hi all, After clarification that the bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668308 is indeed a bug with dmo, I believe it will be useful to mark such bugs with a usertag. I propose such bugs be marked with usertag 'dmo'. If you're not sure how to tag a bug with a usertag, it is the same as sending an email to cont...@bugs.debian.org. You will need the following lines. user debian-multime...@lists.debian.org usertags bug-number dmo The above is using the 'debian-multime...@lists.debian.org' email address. I think using this address would be more official, and it makes for a somewhat smaller web URL to view such tags. That URL is http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=dmo;users=debian-multime...@lists.debian.org. -- ~ Andres I also left instructions in the wiki [1] on how to mark these bugs. 1. http://wiki.debian.org/DebianMultimedia/DevelopPackaging#Bugs_for_packages_found_in_DMO -- ~ Andres ___ 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: gpac_0.4.5+svn4019~dfsg0-3_amd64.changes is NEW
Could the headers not have simply been moved to /usr/include/x86_64-linux-gnu? On Sun, Apr 22, 2012 at 9:02 PM, Debian FTP Masters ftpmas...@ftp-master.debian.org wrote: gpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/gpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb gpac-modules-base_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/gpac-modules-base_0.4.5+svn4019~dfsg0-3_amd64.deb gpac_0.4.5+svn4019~dfsg0-3.debian.tar.gz to main/g/gpac/gpac_0.4.5+svn4019~dfsg0-3.debian.tar.gz gpac_0.4.5+svn4019~dfsg0-3.dsc to main/g/gpac/gpac_0.4.5+svn4019~dfsg0-3.dsc gpac_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/gpac_0.4.5+svn4019~dfsg0-3_amd64.deb (new) libgpac-configuration-dev_0.4.5+svn4019~dfsg0-3_amd64.deb optional libdevel GPAC Project on Advanced Content - arch-specific development files GPAC stands for GPAC Project on Advanced Content (a recursive acronym). It is an Open Source multimedia framework for research and academic purposes. The project covers different aspects of multimedia, with a focus on presentation technologies (graphics, animation and interactivity). . This package contains architecture dependent files that are used for application development. libgpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/libgpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb libgpac-dev_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/libgpac-dev_0.4.5+svn4019~dfsg0-3_amd64.deb libgpac2_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/libgpac2_0.4.5+svn4019~dfsg0-3_amd64.deb Changes: gpac (0.4.5+svn4019~dfsg0-3) unstable; urgency=low . * Move the header gpac/configuration.h into a brand-new libgpac-configuration-dev package and set it to Multi-Arch: foreign in order to avoid multi-arch breakage. (Closes: #66) Override entries for your package: gpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb - extra debug gpac-modules-base_0.4.5+svn4019~dfsg0-3_amd64.deb - optional graphics gpac_0.4.5+svn4019~dfsg0-3.dsc - source graphics gpac_0.4.5+svn4019~dfsg0-3_amd64.deb - optional graphics libgpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb - extra debug libgpac-dev_0.4.5+svn4019~dfsg0-3_amd64.deb - optional libdevel libgpac2_0.4.5+svn4019~dfsg0-3_amd64.deb - optional libs Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 66 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- ~ Andres ___ 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: gpac_0.4.5+svn4019~dfsg0-3_amd64.changes is NEW
Err, I mean /usr/include/$(DEB_HOST_MULTIARCH). On Sun, Apr 22, 2012 at 9:22 PM, Andres Mejia amejia...@gmail.com wrote: Could the headers not have simply been moved to /usr/include/x86_64-linux-gnu? On Sun, Apr 22, 2012 at 9:02 PM, Debian FTP Masters ftpmas...@ftp-master.debian.org wrote: gpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/gpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb gpac-modules-base_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/gpac-modules-base_0.4.5+svn4019~dfsg0-3_amd64.deb gpac_0.4.5+svn4019~dfsg0-3.debian.tar.gz to main/g/gpac/gpac_0.4.5+svn4019~dfsg0-3.debian.tar.gz gpac_0.4.5+svn4019~dfsg0-3.dsc to main/g/gpac/gpac_0.4.5+svn4019~dfsg0-3.dsc gpac_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/gpac_0.4.5+svn4019~dfsg0-3_amd64.deb (new) libgpac-configuration-dev_0.4.5+svn4019~dfsg0-3_amd64.deb optional libdevel GPAC Project on Advanced Content - arch-specific development files GPAC stands for GPAC Project on Advanced Content (a recursive acronym). It is an Open Source multimedia framework for research and academic purposes. The project covers different aspects of multimedia, with a focus on presentation technologies (graphics, animation and interactivity). . This package contains architecture dependent files that are used for application development. libgpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/libgpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb libgpac-dev_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/libgpac-dev_0.4.5+svn4019~dfsg0-3_amd64.deb libgpac2_0.4.5+svn4019~dfsg0-3_amd64.deb to main/g/gpac/libgpac2_0.4.5+svn4019~dfsg0-3_amd64.deb Changes: gpac (0.4.5+svn4019~dfsg0-3) unstable; urgency=low . * Move the header gpac/configuration.h into a brand-new libgpac-configuration-dev package and set it to Multi-Arch: foreign in order to avoid multi-arch breakage. (Closes: #66) Override entries for your package: gpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb - extra debug gpac-modules-base_0.4.5+svn4019~dfsg0-3_amd64.deb - optional graphics gpac_0.4.5+svn4019~dfsg0-3.dsc - source graphics gpac_0.4.5+svn4019~dfsg0-3_amd64.deb - optional graphics libgpac-dbg_0.4.5+svn4019~dfsg0-3_amd64.deb - extra debug libgpac-dev_0.4.5+svn4019~dfsg0-3_amd64.deb - optional libdevel libgpac2_0.4.5+svn4019~dfsg0-3_amd64.deb - optional libs Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 66 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- ~ Andres -- ~ Andres ___ 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: Accepted devede 1:3.21.0-0.1 (source all)
On Apr 18, 2012 3:12 AM, Alessio Treglia ales...@debian.org wrote: On Wed, Apr 18, 2012 at 1:36 AM, Christian Marillat maril...@debian.org wrote: * Another broken package uploaded... What is broken and why? Please elaborate. References: http://www.debian-multimedia.org/lurker/message/20120417.233604.ee7320a1.en.html -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A Filing a bug against devede would have been the appropriate step taken to resolve this issue, not uploading a different package somewhere else. ~ Andres ___ 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: debian-multimedia.org considered harmful - redux
On Apr 13, 2012 2:04 AM, Reinhard Tartler siret...@gmail.com wrote:
On Thu, Apr 12, 2012 at 2:26 PM, Stefano Zacchiroli lea...@debian.org
wrote:
On Wed, Apr 04, 2012 at 01:07:44PM +0200, Alessio Treglia wrote:
Stefano, I think it's time to give you a clear answer, which is:
Hi Alessio et al.,
thank you for this answer and to Andres for having pointed me to past
exchanges on this subject.
I've drafted a message that I'd like to send to Christian publicly
Cc:-ing this list. It is attached to this mail for review by the
pkg-multimedia team. (Yes, I know this is a public list and Christian
will likely read it before the review, but I don't particularly mind: it
will just anticipate a public discussion we'd like to have anyhow.)
As usual, a very well drafted and balanced mail!
I'd appreciate your feedback on it.
Let me comment inline.
In particular, I'd like to know what exactly you'd like to ask d-m.o to
do: I've speculated a request as part of my point (1), but it'd be
better if you could comment on that, to transform my speculation in
something you approve of.
TIA,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
-- Forwarded message --
From: Stefano Zacchiroli lea...@debian.org
To: Christian Marillat maril...@debian.org, maril...@free.fr
Cc: pkg-multimedia-maintainers@lists.alioth.debian.org
Date: Thu, 12 Apr 2012 14:25:45 +0200
Subject: on package duplication between Debian and debian-multimedia
Dear Christian,
as you probably are aware of, there are recurring discussions on the
package duplication between the official Debian archive and the
debian-multimedia.org (d-m.o from now on) that you maintain.
AFAIK, the Debian team in charge of maintaining multimedia packages
(that I'm Cc:-ing) is not happy about the duplication and has approached
you about that [1], providing some evidence of the troubles that it
causes to them and to Debian users that also happen to use d-m.o. OTOH
I'm sure you are maintaining d-m.o to provide a useful service to Debian
users, when some of the packages you distribute are not available in
Debian proper.
[1]
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-March/025498.html
Personally, I think that principle is fine, but I'm worried about the
duplication part. Not only due to the troubles that it might cause, but
also (and more importantly) for the apparent waste of maintenance
energies. Energies that could be put into better use if you and the
pkg-multimedia team could find a way to collaborate, and to do so
contributing to the *official* Debian packaging of the concerned
software.
The harm is not only on the waste of maintainers time side, but also
on the users side. In particular, have a look at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660924, where a
confused user gets very angry because he did not understand my
response (#5). Fabian tried to explain it to him (#10) but it turns
out in #20 that the original reporter did neither understand the
technical notion of an 'epoch' in the version number, nor that d-m.o
is not an official debian mirror.
I agree that this also adds to confusion amongst users and wastes their
time. See bug #668308 message #47. Here a user came to realize that xbmc
does not run with libraries from dmo.
I have no specific opinion on the technical claims that d-m.o causes
trouble to official Debian packages. That might be true or not. Ditto
for your allegations of conflict of interest in the maintenance of
ffmpeg or libav in Debian. But I observe that *in* Debian we do have
mechanisms to solve that kind of issues, if and when they arise. As long
as you keep on doing your work outside Debian instead of raising your
concerns within Debian, we'll have to keep on assuming that what is
being done in Debian is fine and is entitled to the official status that
come with the name Debian.
Thinking about it, I think we should choose one of the two possible way
forward:
1) You and the pkg-multimedia team reach an agreement on
which-packages-belong-where. I speculate their request would be that
for every package that exist in the official Debian archive, the same
package should not exist in d-m.o, unless it has a version that does
not interfere with the official packages in standard Debian
installations.
Well, I guess renaming packages, and for shared libraries changing
sonames, would be acceptable as well. Note that this has been done for
the FFmpeg library packages in the past. It turned out to be quite
some pain, but maintaing the custom soname is surely feasible.
I understand that
Re: debian-multimedia.org considered harmful - redux
On Apr 13, 2012 7:35 PM, Benjamin Drung bdr...@debian.org wrote: On Do, 2012-04-12 at 14:26 +0200, Stefano Zacchiroli wrote: On Wed, Apr 04, 2012 at 01:07:44PM +0200, Alessio Treglia wrote: Stefano, I think it's time to give you a clear answer, which is: Hi Alessio et al., thank you for this answer and to Andres for having pointed me to past exchanges on this subject. I've drafted a message that I'd like to send to Christian publicly Cc:-ing this list. Thanks for your draft. I'd appreciate your feedback on it. As stated by others, we should ask him to add a clear statement/disclaimer on his homepage that his repository is not part of Debian and that the donations are not targeting Debian. In case he don't want to increase the cooperation with us, he should also make the distinction between pkg-multimedia and d-m.o clear. In particular, I'd like to know what exactly you'd like to ask d-m.o to do: I've speculated a request as part of my point (1), but it'd be better if you could comment on that, to transform my speculation in something you approve of. Point (1) is nicely phrased and I support it. The agreement should (at least) cover all binary package that are also available the official Debian archive. I will be happy to work with him to get his changes to the packages into Debian. He could be invited to join pkg-multimedia-maintainers and work on the package inside Debian. Bumping the epoch for binary packages that are available in Debian is a no-go for us. He either needs to revert the epoch-bump changes or rename the binary packages if he decides to go way (1). -- Benjamin Drung Debian Ubuntu Developer Christian went ahead and uploaded the devede package to dmo with an epoch bump after devede was uploaded to Debian. This doesn't give me any confidence that Christian is willing to work with the team at all (much less properly file bug reports or do any kind of work within the Debian infrastructure). ~ Andres ___ 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: Accepted devede 1:3.21.0-0.1 (source all)
On Apr 19, 2012 11:30 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.04.2012 17:09, schrieb Andres Mejia: Filing a bug against devede would have been the appropriate step taken to resolve this issue, not uploading a different package somewhere else. Sorry, but *which* issue. Has there been a response from Christian? - Fabian Christian hasn't elaborated and I haven't seen any new issues against devede in the BTS. ~ Andres ___ 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: devede_3.21.0-1_amd64.changes ACCEPTED into unstable
On Apr 17, 2012 2:32 PM, Debian FTP Masters ftpmas...@ftp-master.debian.org wrote: Accepted: devede_3.21.0-1.debian.tar.gz to main/d/devede/devede_3.21.0-1.debian.tar.gz devede_3.21.0-1.dsc to main/d/devede/devede_3.21.0-1.dsc devede_3.21.0-1_all.deb to main/d/devede/devede_3.21.0-1_all.deb devede_3.21.0.orig.tar.bz2 to main/d/devede/devede_3.21.0.orig.tar.bz2 Changes: devede (3.21.0-1) unstable; urgency=low . * Initial release. (Closes: #447276) Override entries for your package: devede_3.21.0-1.dsc - optional video devede_3.21.0-1_all.deb - optional video Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 447276 Thank you for your contribution to Debian. Hey great job! Handbrake was also mentioned as a very popular app to get into Debian. I don't necessarily have time to look at handbrake however. ~ Andres ___ 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: debian-multimedia.org considered harmful - redux
On Apr 12, 2012 10:38 AM, Fabian Greffrath fab...@greffrath.com wrote: Dear Stefano, Am 12.04.2012 14:26, schrieb Stefano Zacchiroli: I'd appreciate your feedback on it. thank you very much for the draft. Same here, thank you. However, sadly, I doubt this will lead us anywhere. I do not believe that Christian will ever change the domain name of his repository now that it is that established - and I am not sure if this is really something we should demand from him. So, IMHO, step (2) will never happen. From what I've seen, he only established debian-multimedia.org in 2006 (do a whois on the site). There has been activity involving the Debian Multimedia team since at least 2003, judging by the debian-multimedia@l.d.omailing list. Seeing as it looks like he never intended to join the team anyway, he needs to change the name back to whatever he was using before (he was on some site called nerim.net) or use some other name. OTOH, we have approached Christian several times before with words similar to what you used in the draft. I don't expect that another approach will change his mind and attitude regarding collaboration with us - and I think that he knows himself quite well that the package duplication that he introduces causes harm and pollutes the Debian package name space. That's really nothing we we should need to educate him about at all. I too tend to think Christian is well aware of what he's doing. He's a DD afterall and he even maintained gnome packages back in 2002 (search for christian marillat once again). I think there are two other steps that we can demand from him: (1) There should be a clear statement/disclaimer on the d-m.o homepage telling users that this is an unofficial repository that is not affiliated to Debian in general and the pkg-multimedia team in particular and that using packages from this repository is at own risk. A properly worded disclaimer can be found e.g. on the medibuntu homepage. Yes, whatever site he ends up using, it needs to be clear it's not affiliated with Debian. Apparently, there are users out there that think it is. There are users who think dmo is needed for multimedia applications. I think users who end up with this confusion are those that used RPM distros. Fedora has RPM Fusion and OpenSUSE has Packman. In the cases of these additional repositories, it's clear they are not a part of the distros they provide an extension to. Dmo needs to do the same. (2) There should be a clarification on the homepage that the Donations collected on the page are not targeted at Debian but only at d-m.o itself. These two claims are IMHO absolutely important! Agreed, just like how it needs to be clear dmo is not a part of Debian, it also needs to be clear donations towards dmo do not go towards Debian. Thanks again, 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 ___ 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: Update Wiki FAQ
On Sun, Apr 8, 2012 at 10:17 AM, AV Linux i...@bandshed.net wrote: Hi, Thanks very much for taking time to reply, I'm relieved to see it is still there in the links in good company with the other mentioned projects. BTW the Studio-to-go link no longer has a domain so perhaps should be removed or updated. Also the KXStudio project might be worth mentioning if it fits your criteria, I would assume it uses/shares a lot of upstream code with pkg-multimedia in Debian. Best Regards -GLEN Ok, page was updated. BTW, you're free (and anyone is free) to edit the wiki page yourself. You should consider having your distro added to http://www.debian.org/misc/children-distros. -- ~ Andres ___ 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: Update Wiki FAQ
Apr 5, 2012 1:00 PM, AV Linux i...@bandshed.net wrote: Hi, Sorry to butt in here, I just re-read the wiki and it used to refer to AV Linux as a 'multimedia' Debian based project. Was it removed intentionally? If so that is your prerogative of course, I will say that I have no ill-will against the team and if there was issues with AV Linux and the Debian multimedia team that necessitated it's removal from the wiki I would hope that you would let me know as a subscriber to the list. My use of Stable as a base is one of many legitimate reasons that I am not a team member certainly not out of unwillingness to co-operate. At any rate the AV Linux project is 'outside' of Debian and not a sanctioned blend so that probably is explanation enough. However the fact it was previously listed has me curious. Keep up the great work. -GLEN Am Mittwoch, den 04.04.2012, 21:07 -0400 schrieb Andres Mejia: Just updated the FAQ in the wiki. See http://wiki.debian.org/DebianMultimedia/FAQ These are updates about dmo. In particular, they answer the common questions of do we coordinate with dmo (no) do we support packages from dmo (no) and is dmo a part of Debian (no). Improvements are welcome. Wouldn't it be better to always write the full name instead of using 'dmo'? It's clear to us, what dmo stands for, but that's not clear to everyone. -- Benjamin Drung Debian Ubuntu Developer ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers It was moved to a subsection. Check DebianMultimedia/Links. ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
libav strict internal shlibs dependencies
I see the strict internal dependencies was added long ago. [1] Is this something that is still needed? I imagine each of the libraries don't need these strict dependencies with one another anymore, and if it still does, it should be bug. libpostproc will soon be it's own package. Any thoughts on these strict shlib dependencies removal? 1. http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=a1229f8ace3f5cf129685b26d9ef212637caa3b9;hp=b5c2d2d409e03c239ba1df50247516f73eff3669 -- ~ Andres ___ 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: debian-multimedia.org considered harmful - redux
On Apr 4, 2012 7:07 AM, Alessio Treglia ales...@debian.org wrote: Ave Stefano, hi all, and sorry for the delay, I chose to wait in silence and see if things could get better without becoming unfriendly. However now, after having seen this [1], I am convinced he's kidding us. On Mon, Mar 19, 2012 at 10:44 AM, Fabian Greffrath fab...@greffrath.com wrote: I'd like to know if, in the opinion of the Debian Multimedia Team as a whole, debian-multimedia.org is currently more harmful than useful to the Debian Project and its users. Stefano, I think it's time to give you a clear answer, which is: Yes, we consider debian-multimedia.org more harmful than useful to the Debian Project and its users. Thanks for your time and work, cheers! [1] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-April/025861.html -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers This also would violate the Debian Machine Usage Policy, paragraph saying don't by any willful, deliberate, reckless, or unlawful act interfere with the work of another developer... Furthermore, with the emails I exchanged with Christian and now this, it's clear he's not interested in working with the team. As far as I'm concerned, dmo is some project completely separate from Debian and I'm not going to waste anymore time or effort dealing with any issues arising from its use. Dmo is none of my concern. ~ Andres ___ 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: debian-multimedia.org considered harmful - redux
On Apr 4, 2012 2:20 PM, Stefano Zacchiroli lea...@debian.org wrote:
On Wed, Apr 04, 2012 at 01:07:44PM +0200, Alessio Treglia wrote:
Stefano, I think it's time to give you a clear answer, which is:
Yes, we consider debian-multimedia.org more harmful than useful
to the Debian Project and its users.
Thanks Alessio. If there are other voices on this matter, please speak
up. I'd be glad to volunteer to contact, again, Christian to come to an
amicable solution if possible. But I don't want to discover half-way
through that the team opinions on this matter are more diverse than what
it seems from the complaint threads.
I'll postpone the issue for a week more or so, before contacting
Christian. Please speak up before then if you feel any differently than
Alessio's quote above.
Similarly, if you object to me contacting Christian on behalf of the
Project and this team: please speak up.
I've also another request before proceeding. It has been mentioned in
various occasions that the team attempted to discuss the ongoing issues
with Christian in the past. Did that happen publicly? Can someone point
me to the relevant exchanges?
TIA,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Find the threads on pkg-multimedia-maintainers list from last month with
subject lines 'Duplicate Packages from Debian archive in DMO' and 'Helping
with Maintenance of Packages in Debian.' The threads are broken
unfortunately, thanks to Christian for not CCing the list even when
requested to do so.
~ Andres
___
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#667573: x264: 10 bit builds
Package: x264 Version: 2:0.120.2171+git01f7a33-3 Severity: wishlist Reporting this to open discussion on this. It looks like 10 bit h264 encoding is becoming the norm. We should allow some way to support both 10 bit and 8 bit builds of x264, possibly making use of the alternatives system. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages x264 depends on: ii libavcodec-extra-53 5:0.8.1-4 ii libavformat-extra-53 4:0.8~beta2.2 ii libavformat53 [libavformat-extra-53] 5:0.8.1-4 ii libavutil-extra-514:0.8.0.1+b1 ii libavutil51 [libavutil-extra-51] 5:0.8.1-4 ii libc6 2.13-27 ii libffms2-22.17-1 ii libpostproc-extra-52 4:0.8~beta2.2 ii libpostproc52 [libpostproc-extra-52] 5:0.8.1-4 ii libswscale-extra-24:0.8~beta2.2 ii libswscale2 [libswscale-extra-2] 5:0.8.1-4 ii libx264-120 2:0.120.2171+git01f7a33-3 ii zlib1g1:1.2.6.dfsg-2 x264 recommends no packages. x264 suggests no packages. -- no debconf 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
Update Wiki FAQ
Just updated the FAQ in the wiki. See http://wiki.debian.org/DebianMultimedia/FAQ These are updates about dmo. In particular, they answer the common questions of do we coordinate with dmo (no) do we support packages from dmo (no) and is dmo a part of Debian (no). Improvements are welcome. -- ~ Andres ___ 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#667583: override: libav binary packages
Package: ftp.debian.org Severity: normal The override needs to be updated for all these packages. libavdevice-extra-53_0.8.1-4_all.deb: package says section is oldlibs, override says libs. libavdevice-extra-53_0.8.1-4_all.deb: package says priority is extra, override says optional. libavfilter-extra-2_0.8.1-4_all.deb: package says section is oldlibs, override says libs. libavfilter-extra-2_0.8.1-4_all.deb: package says priority is extra, override says optional. libavformat-extra-53_0.8.1-4_all.deb: package says section is oldlibs, override says libs. libavformat-extra-53_0.8.1-4_all.deb: package says priority is extra, override says optional. libavutil-extra-51_0.8.1-4_all.deb: package says section is oldlibs, override says libs. libavutil-extra-51_0.8.1-4_all.deb: package says priority is extra, override says optional. libpostproc-extra-52_0.8.1-4_all.deb: package says section is oldlibs, override says libs. libpostproc-extra-52_0.8.1-4_all.deb: package says priority is extra, override says optional. libswscale-extra-2_0.8.1-4_all.deb: package says section is oldlibs, override says libs. libswscale-extra-2_0.8.1-4_all.deb: package says priority is extra, override says optional. These are all transitional packages now and thus should have priority extra in section oldlibs. ___ 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#666765: lintian: Add libav libraries to embedded-library check
Package: lintian
Version: 2.5.6
Severity: wishlist
Tags: patch
Embedded libav libraries should be checked for in the 'embedded-library' check.
Reasons for this are as follow.
* libav is a heavily used multimedia library. Many multimedia related packages
(apps, frameworks, etc.) use libav in one form or another.
* libav sees at least 10 security related fixes each point release.
* In Debian, it was already expected that no package should use an embedded
copy of any of the libav libraries.
Attached is a patch that will add the libav libraries into the
'embedded-libraries' lintian check.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages lintian depends on:
ii binutils 2.22-6
ii bzip2 1.0.6-1
ii diffstat 1.55-2
ii file 5.11-1
ii gettext0.18.1.1-5
ii intltool-debian0.35.0+20060710.1
ii libapt-pkg-perl0.1.26
ii libc-bin 2.13-27
ii libclass-accessor-perl 0.34-1
ii libclone-perl 0.31-1+b2
ii libdpkg-perl 1.16.2
ii libemail-valid-perl0.187-2
ii libipc-run-perl0.91-1
ii libparse-debianchangelog-perl 1.2.0-1
ii libtimedate-perl 1.2000-1
ii liburi-perl1.60-1
ii locales2.13-27
ii locales-all [locales] 2.13-27
ii man-db 2.6.1-2
ii patchutils 0.3.2-1.1
ii perl [libdigest-sha-perl] 5.14.2-9
ii unzip 6.0-6
lintian recommends no packages.
Versions of packages lintian suggests:
ii binutils-multiarch none
ii dpkg-dev 1.16.2
ii libhtml-parser-perl3.69-1+b1
ii libtext-template-perl 1.45-2
ii man-db 2.6.1-2
ii xz-utils 5.1.1alpha+20110809-3
-- no debconf information
From 9d3349195b9618aab5f7e1c67e4094400edc5392 Mon Sep 17 00:00:00 2001
From: Andres Mejia amejia...@gmail.com
Date: Sat, 31 Mar 2012 16:19:50 -0400
Subject: [PATCH] Add check for embedded libav/ffmpeg libraries. It seems that
libav/ffmpeg gets at least 10 security fixes every point
release. A point release seems to be made once every 2
months. Given this, embedding the libav/ffmpeg libs in an
app should now be an error.
---
checks/binaries |7 +++
1 file changed, 7 insertions(+)
diff --git a/checks/binaries b/checks/binaries
index 2117659..57f103d 100644
--- a/checks/binaries
+++ b/checks/binaries
@@ -119,6 +119,13 @@ our %EMBEDDED_LIBRARIES = (
'glee' = qr'Extension name exceeds 1023 characters.',
'glew' = qr'Missing GL version',
'libtheora' = qr'Xiph.Org libtheora ',
+'libavcodec'= qr'insufficient thread locking around avcodec_open/close\(\)\n',
+'libavdevice' = qr'Soundcard does not support 16 bit sample format\n',
+'libavfilter' = qr'Buffer video frames, and make them accessible to the filterchain.',
+'libavformat' = qr'Format detected only with low score of %d, misdetection possible!\n',
+'libavutil' = qr'AVOption type %d of option %s not implemented yet\n',
+'libpostproc' = qr'using npp filters 0x%X/0x%X\n',
+'libswscale'= qr'Exactly one scaler algorithm must be chosen\n',
);
our $MULTIARCH_DIRS = Lintian::Data-new('binaries/multiarch-dirs', '\s+');
--
1.7.9.5
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
lintian 'embedded-libraries' check for libav libs
Any package distributed through Debian is not suppose to use embedded libav libraries. This seemed like an unwritten rule, and people in debian-devel had this understanding as well. Now that it seems libav gets at least 10 security fixes every point release, I believe this merits adding checks for the libav libraries to the 'embedded-libraries' lintian check. Note having embedded libraries is an error. The following patch does this. I tested with mplayer2 (which passes) and the mythtv package in Ubuntu (which fails all of the new tests). Any feedback before I submit this to lintian? -- ~ Andres 0001-Add-check-for-embedded-libav-ffmpeg-libraries.patch Description: Binary data ___ 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: [SCM] libav/libav-extra: Change packaging to only build libavcodec-extra* package. Other extra packages are unnecessary.
On Mar 29, 2012 2:39 PM, Reinhard Tartler siret...@gmail.com wrote: On Wed, Mar 21, 2012 at 3:26 AM, ceros-gu...@users.alioth.debian.org wrote: The following commit has been merged in the libav-extra branch: commit 1b7ca8d372075118db12c8f1d8fb565eca874183 Author: Andres Mejia amejia...@gmail.com Date: Tue Mar 20 22:26:21 2012 -0400 Change packaging to only build libavcodec-extra* package. Other extra packages are unnecessary. diff --git a/debian/changelog b/debian/changelog index 1216cbc..47d8535 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +libav (5:0.8.1-2) UNRELEASED; urgency=low Any particular reason why you bumped the epoch here from 4: to 5:? -- regards, Reinhard 0.8.1 was less than libav-extra's version of 0.8.1.*, so I had to bump the epoch to allow smoother transition extra packages which are now built in libav. ~ Andres ___ 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: Helping with Maintenance of Packages in Debian
On Mar 28, 2012 2:14 AM, Christian Marillat maril...@free.fr wrote: Andres Mejia amejia...@gmail.com writes: Hi Christian, So I'll ask one more time and if the answer is no (or you don't respond), I won't bother you anymore. For the packages in DMO that can now be uploaded to Debian, will you be willing to help upload and maintain those packages in Debian? I can upload ffmpeg in Debian ? Christian Uploading ffmpeg would be a bad idea. Aside from the package name conflicts, libav and ffmpeg are incompatible with each other. Trying to keep them abi/api compatible would be a lot of work, more than what I have time for at least. If you want to upload ffmpeg and still have them compatible, feel free to submit your patches to libav/ffmpeg. Another alternative is to have the libraries renamed, of which case you will still need to submit patches upstream. ~ Andres ___ 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: [SCM] libav/master: Seperate the ffmpeg program into the transitional package.
On Mar 28, 2012 3:48 AM, Reinhard Tartler siret...@gmail.com wrote:
On Tue, Mar 27, 2012 at 8:44 PM, ceros-gu...@users.alioth.debian.org
wrote:
The following commit has been merged in the master branch:
commit ea819ac5706a98397a834d8f9a6972d92210e969
Author: Andres Mejia amejia...@gmail.com
Date: Tue Mar 27 14:44:27 2012 -0400
Seperate the ffmpeg program into the transitional package.
diff --git a/debian/control b/debian/control
index 2f6df67..1421f10 100644
--- a/debian/control
+++ b/debian/control
@@ -64,6 +64,8 @@ Build-Depends:
Package: libav-tools
Section: video
Architecture: any
+Provides:
+ ffmpeg
This is wrong, because this breaks versioned dependencies on the
'ffmpeg' package AFAIUI.
Is there a package out there that needs a specific version of ffmpeg?
I think we have to keep the 'ffmpeg' package depending on 'libav-tools'.
Right, and it still will.
BTW, ffmpeg.c has already been removed from the master branch of libav.git
Replaces:
ffmpeg ( 4:0.8~),
libavcodec-extra-53 ( 4:0.6~),
@@ -88,7 +90,7 @@ Description: Multimedia player, server, encoder and
transcoder
Package: ffmpeg
Section: oldlibs
Priority: extra
-Architecture: all
+Architecture: any
Depends:
libav-tools,
${misc:Depends},
@@ -97,8 +99,9 @@ Description: Multimedia player, server, encoder and
transcoder (transitional pac
Libav is a complete, cross-platform solution to decode, encode, record,
convert and stream audio and video.
.
- This package is only used for transitional purposes and can be safely
- removed when no other packages depend on this package.
+ This package contains the deprecated ffmpeg program. This package
also serves
+ as a transitional package to libav-tools. Users are advised to use
avconv from
+ the libav-tools package instead of ffmpeg.
Package: ffmpeg-dbg
Section: oldlibs
@@ -116,13 +119,19 @@ Description: Debug symbols for Libav related
packages (transitional package)
Most people will not need this package. Please install it to produce
useful
stacktraces to help debugging the Libav libraries.
.
- This package is only used for transitional purposes and can be safely
- removed.
+ This package contains the debug symbols for the deprecated ffmpeg
program.
+ It also serves as a transitional package to libav-tools-dbg.
Package: libav-dbg
Section: debug
Priority: extra
Architecture: any
+Provides:
+ ffmpeg-dbg
+Replaces:
+ ffmpeg-dbg ( 5:0.8.1-3)
+Breaks:
+ ffmpeg-dbg ( 5:0.8.1-3)
Depends:
libav-tools (= ${binary:Version}),
libavdevice53 (= ${binary:Version}),
diff --git a/debian/ffmpeg.install b/debian/ffmpeg.install
new file mode 100644
index 000..793de72
--- /dev/null
+++ b/debian/ffmpeg.install
@@ -0,0 +1,2 @@
+usr/bin/ffmpeg
+usr/share/man/man1/ffmpeg.1
diff --git a/debian/rules b/debian/rules
index 9748ecc..b955a6c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -125,10 +125,13 @@ install-common: build $(DH_INSTALL_FILES)
install -m 644 -D debian-shared/doc/*.html
debian/tmp/usr/share/doc/libav/html/
install -m 644 -D doc/avserver.conf debian/tmp/etc/
install -m 644 -D debian-shared/tools/qt-faststart
debian/tmp/usr/bin/qt-faststart
- dh_install $(addprefix -N,$(LIB_EXTRA_PKGS))
-Xusr/share/doc/libav-doc \
+ dh_install $(addprefix -N,$(LIB_EXTRA_PKGS)) -Nffmpeg
-Xusr/bin/ffmpeg \
+ -Xusr/share/man/man1/ffmpeg.1 -Xusr/share/doc/libav-doc
\
-Xusr/share/doc/libav --fail-missing
--sourcedir=debian/tmp
- dh_strip $(addprefix -N,$(LIB_PKGS2)) --dbg-package=libav-dbg
+ dh_install -pffmpeg --sourcedir=debian/tmp
+ dh_strip $(addprefix -N,$(LIB_PKGS2)) -Nffmpeg
--dbg-package=libav-dbg
dh_strip $(addprefix -p,$(LIB_PKGS2))
--dbg-package=libav-regular-dbg
+ dh_strip -pffmpeg --dbg-package=ffmpeg-dbg
env
LD_LIBRARY_PATH=$(LD_LIBRARY_PATH):$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)
\
debian/tmp/usr/bin/avconv -formats | tee formats.txt
env
LD_LIBRARY_PATH=$(LD_LIBRARY_PATH):$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)
\
--
Libav/FFmpeg packaging
___
pkg-multimedia-commits mailing list
pkg-multimedia-comm...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-commits
--
regards,
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
___
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#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
On Tue, Mar 27, 2012 at 4:53 PM, Andreas Beckmann deb...@abeckmann.de wrote:
Hi Andres,
you need to Cc: the bug submitter if you expect answers.
For libvdpau please see
debian/patches/vdpau-module-searchpath.patch
where I sanitized the searching to look in \${ORIGIN}/vdpau/,
$libdir/vdpau/, /usr/lib/vdpau/.
dlopen() does the right thing, i.e. won't load a mismatching
library (e.g. 32bit into a 64bit programm).
Andreas
I would feel more comfortable if this were forwarded upstream. You may
want to forward a patch to them yourself. Right now, this isn't in my
list of priorities.
--
~ Andres
___
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: Duplicate Packages from Debian archive in DMO
On Fri, Mar 23, 2012 at 11:09 AM, Christian Marillat maril...@free.fr wrote: Andres Mejia amejia...@gmail.com writes: On Mar 22, 2012 11:29 AM, Christian Marillat maril...@free.fr wrote: Andres Mejia amejia...@gmail.com writes: On Mar 21, 2012 2:26 AM, Christian Marillat maril...@free.fr wrote: Andres Mejia amejia...@gmail.com writes: [...] Also some pakcages like vlc or xine are in my repository because Debian added a conflicts against libavutil51 from my repository. [...] I looked at the packaging for vlc and xine-lib. I don't see a place where a conflicts to any libav/ffmpeg libraries was added. , | $ apt-cache show libpostproc52 | Package: libpostproc52 | Source: libav | Version: 4:0.8.1-1 | Installed-Size: 403 | Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org | Architecture: i386 | Depends: libavutil51 (= 4:0.8.1-1) | libavutil-extra-51 (= 4:0.8.1), libavutil51 ( 4:0.8.1-99) | libavutil-extra-51 ( 4:0.8.1.99), libc6 (= 2.4) ` Could you explain the libavutil51 ( 4:0.8.1-99) | libavutil-extra-51 ( 4:0.8.1.99) in Depends field ? You're looking at the strict dependencies set only for the libav packages. The shlibs is generated again so that the Depends field above does not apply to any packages depending on the libav libraries. See vlc for example. vlc-nox, libxine2-ffmpeg and libxine1-ffmpeg depends on libpostproc52 and installing libpostproc52 from Debian remove these packages : , | LANG=C sudo apt-get install libpostproc52=4:0.8.1-1 | Reading package lists... Done | Building dependency tree | Reading state information... Done | The following packages were automatically installed and are no longer | required: | libva-x11-1 libxcb-keysyms1 libresid-builder0c2a libxcb-xv0 libtar0 | libxcb-xfixes0 libcddb2 libwebp2 libdvbpsi7 libdirac-decoder0 libqtcore4 | libupnp3 libxcb-randr0 libxcb-composite0 libiso9660-7 libsidplay2 | libqtgui4 libaudio2 libvcdinfo0 libebml3 libmatroska5 libsdl-image1.2 | Use 'apt-get autoremove' to remove them. | The following extra packages will be installed: | libavcodec-extra-53 libavutil-extra-51 | Suggested packages: | libfaad0 | The following packages will be REMOVED: | ffmpeg libavcodec53 libavdevice53 libavfilter2 libavformat53 libavutil51 | libswresample0 libswscale2 ` Yes, this is because of the internal shlib dependencies between the libav shared libraries and programs. This was done to ensure the libav/ffmpeg libraries installed in a system are from the same version. Also, the libav and ffmpeg libraries are incompatible with each other, so the strict dependencies prevents this kind of breakage as well. [...] Speaking of libav/ffmpeg, the Debian archive has libav and not ffmpeg. I see that DMO is the reverse, shipping ffmpeg instead of libav. This of course resulted in many breakages between packages in Debian and packages in DMO. Which breakage ? Tell me what is exactly broken. Here are some of the more recent reported problems with using dmo. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663893 The latest comment in the bug report is from the Debian maintainer : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663893#139 , | On a test installation running debian-multimedia here moc works fine, ` Works also fine for me. 2. http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-March/025352.html # read the quoted message 3. http://lists.debian.org/debian-devel/2012/03/msg00129.html About 2 and 3, I can personally attest that this kind of breakage with using dmo does happen. Years ago when I first switched to Debian, I too thought that using dmo would be alright, seeing that it should only provide missing codecs and other software not available in Debian at the time. Long story short, after certain packages were upgraded because of dmo being activated on my system, I was left with numerous package conflicts and a missing desktop environment (in my case, kde). 2 thread started with a newbie Debian user who don't understand how Debian packaging and just saying as I'm unable to downgrade a packages dmo shouldn't exist. 3 is message from angry people who are only saying dmo is crap without doing any example. [...] Could you tell me why I should move to libav ? I'm packaging ffmpeg for 11 years and I'm happy with that. If you're comfortable packaging ffmpeg, then packaging libav should be no problem to you at all. One of the main reasons cited for why Debian (and Ubuntu) went with libav was because it would offer more stability, something desirable with respect to maintaining a distro such as Debian. See this link. https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html Already read. I think here is a conflict of interest. I'm sure if Reinhard Tartler wasn't the libav release manager, we are not talking about
Re: faac_1.28-4_amd64.changes REJECTED
On Sat, Mar 24, 2012 at 6:49 AM, Luca Falavigna ftpmas...@debian.org wrote: Hi! Copyright says: Those intending to use this software module in hardware or software products are advised that this use may infringe existing patents. This conflicts with http://www.debian.org/legal/patent, Policy statement §1. Cheers, Luca === 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. Hi, I read the policy statement, but it's not clear to me how policy statement 1 applies to this line. The copyright disclaimer above says ...this use *may* infringe existing patents. This doesn't make it clear that this software module *does* or *does not* infringe existing patents. I don't believe this makes the situation any different than packages (both multimedia related and non-multimedia related) that are distributed in main. Note that faac is proposed for inclusion in non-free for a different reason. It has to do with this statement. Copyright is not released for non MPEG-2 NBC/MPEG-4 Audio conforming products. For a discussion on the matter whether or not faac is at least redistributable, see [1]. 1. http://ffmpeg.org/pipermail/ffmpeg-devel/2009-April/060411.html -- ~ Andres ___ 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: Splitting libav-tools
On Sat, Mar 24, 2012 at 3:18 AM, Reinhard Tartler siret...@gmail.com wrote: On Sat, Mar 24, 2012 at 1:19 AM, Andres Mejia amejia...@gmail.com wrote: I believe the libav-tools package should be split and the separate binary programs each be installed in their own package. Out of all the programs from libav/ffmpeg, I've rarely used ffplay, and I never used the server or probe programs. I've been thinking about this as well, but TBH, I don't really see the gain. Splitting avplay out of libav-tools would save 17 library dependencies: +libasyncns.so.0 +libcaca.so.0 +libdbus-1.so.3 +libFLAC.so.8 +libjson.so.0 +libncursesw.so.5 +libnsl.so.1 +libpulsecommon-1.1.so +libpulse-simple.so.0 +libpulse.so.0 +libresolv.so.2 +libSDL-1.2.so.0 +libslang.so.2 +libsndfile.so.1 +libtinfo.so.5 +libwrap.so.0 In particular, it would not save you from X11 related dependencies, thanks to the libva. TBH, I'm not entirely convinced that there is much gain in splitting these. If we do it, libav-tools should stay as meta package that depends on all three tiny packages. I was thinking more in terms of decreasing the installed size between the different programs. avplay and avserver don't need the presets in /usr/share/avconv, right? It would also help if the server be it's own package, complete with sysvinit (or systemd or upstart) scripts. avserver is not really useful without proper configuration. You need to tell it what kind of streams to provide on what port, etc. For this reason, I'm not even sure if providing a conffile in /etc/avserver.conf is a great idea. Maybe we should move it from /etc/ to /usr/share/doc/avserver/avserver.conf or something. In that place we, could then also install example start up scripts. -- regards, 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 -- ~ Andres ___ 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: faac_1.28-4_amd64.changes is NEW
On Mar 23, 2012 4:16 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 23.03.2012 03:47, schrieb Debian FTP Masters: * Add Build-Depends: libmp4v2-dev (= 1.9.1). This should probably get reverted, as GPL'ed and MPL'ed code linked together results in something unredistributable by Debian. - Fabian So only the library will be built for now then. Ok. Has anyone asked mp4v2 devs if they would allow use of their library for gpl code? If so, then this would be ok I think. ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Fwd: Re: Duplicate Packages from Debian archive in DMO
FYI, here is Christian's latest response. ~ Andres -- Forwarded message -- From: Christian Marillat maril...@free.fr Date: Mar 23, 2012 11:09 AM Subject: Re: Duplicate Packages from Debian archive in DMO To: dmo-discuss...@debian-multimedia.org Andres Mejia amejia...@gmail.com writes: On Mar 22, 2012 11:29 AM, Christian Marillat maril...@free.fr wrote: Andres Mejia amejia...@gmail.com writes: On Mar 21, 2012 2:26 AM, Christian Marillat maril...@free.fr wrote: Andres Mejia amejia...@gmail.com writes: [...] Also some pakcages like vlc or xine are in my repository because Debian added a conflicts against libavutil51 from my repository. [...] I looked at the packaging for vlc and xine-lib. I don't see a place where a conflicts to any libav/ffmpeg libraries was added. , | $ apt-cache show libpostproc52 | Package: libpostproc52 | Source: libav | Version: 4:0.8.1-1 | Installed-Size: 403 | Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org | Architecture: i386 | Depends: libavutil51 (= 4:0.8.1-1) | libavutil-extra-51 (= 4:0.8.1), libavutil51 ( 4:0.8.1-99) | libavutil-extra-51 ( 4:0.8.1.99), libc6 (= 2.4) ` Could you explain the libavutil51 ( 4:0.8.1-99) | libavutil-extra-51 ( 4:0.8.1.99) in Depends field ? You're looking at the strict dependencies set only for the libav packages. The shlibs is generated again so that the Depends field above does not apply to any packages depending on the libav libraries. See vlc for example. vlc-nox, libxine2-ffmpeg and libxine1-ffmpeg depends on libpostproc52 and installing libpostproc52 from Debian remove these packages : , | LANG=C sudo apt-get install libpostproc52=4:0.8.1-1 | Reading package lists... Done | Building dependency tree | Reading state information... Done | The following packages were automatically installed and are no longer | required: | libva-x11-1 libxcb-keysyms1 libresid-builder0c2a libxcb-xv0 libtar0 | libxcb-xfixes0 libcddb2 libwebp2 libdvbpsi7 libdirac-decoder0 libqtcore4 | libupnp3 libxcb-randr0 libxcb-composite0 libiso9660-7 libsidplay2 | libqtgui4 libaudio2 libvcdinfo0 libebml3 libmatroska5 libsdl-image1.2 | Use 'apt-get autoremove' to remove them. | The following extra packages will be installed: | libavcodec-extra-53 libavutil-extra-51 | Suggested packages: | libfaad0 | The following packages will be REMOVED: | ffmpeg libavcodec53 libavdevice53 libavfilter2 libavformat53 libavutil51 | libswresample0 libswscale2 ` [...] Speaking of libav/ffmpeg, the Debian archive has libav and not ffmpeg. I see that DMO is the reverse, shipping ffmpeg instead of libav. This of course resulted in many breakages between packages in Debian and packages in DMO. Which breakage ? Tell me what is exactly broken. Here are some of the more recent reported problems with using dmo. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663893 The latest comment in the bug report is from the Debian maintainer : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663893#139 , | On a test installation running debian-multimedia here moc works fine, ` Works also fine for me. 2. http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-March/025352.html # read the quoted message 3. http://lists.debian.org/debian-devel/2012/03/msg00129.html About 2 and 3, I can personally attest that this kind of breakage with using dmo does happen. Years ago when I first switched to Debian, I too thought that using dmo would be alright, seeing that it should only provide missing codecs and other software not available in Debian at the time. Long story short, after certain packages were upgraded because of dmo being activated on my system, I was left with numerous package conflicts and a missing desktop environment (in my case, kde). 2 thread started with a newbie Debian user who don't understand how Debian packaging and just saying as I'm unable to downgrade a packages dmo shouldn't exist. 3 is message from angry people who are only saying dmo is crap without doing any example. [...] Could you tell me why I should move to libav ? I'm packaging ffmpeg for 11 years and I'm happy with that. If you're comfortable packaging ffmpeg, then packaging libav should be no problem to you at all. One of the main reasons cited for why Debian (and Ubuntu) went with libav was because it would offer more stability, something desirable with respect to maintaining a distro such as Debian. See this link. https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html Already read. I think here is a conflict of interest. I'm sure if Reinhard Tartler wasn't the libav release manager, we are not talking about libav in Debian but instead ffmpeg. Christian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org
Re: d-m.o dependency tree
2012/2/10 Fabian Greffrath fab...@greffrath.com: Am 09.02.2012 16:49, schrieb Sebastian Dröge: Not obsoleted (yet). faac supports 1-6 channels and the main, lc, ssr and ltp profiles. vo-aacenc only supports 1-2 channels and the lc profile. OK, so it's good enough for the usual CD ripping. The current gnome-media-profiles still uses the faac plugin, right? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers Whatever became of this? Should faac be uploaded to non-free at least for now? -- ~ Andres ___ 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: Duplicate Packages from Debian archive in DMO
On Mar 22, 2012 11:29 AM, Christian Marillat maril...@free.fr wrote: Andres Mejia amejia...@gmail.com writes: On Mar 21, 2012 2:26 AM, Christian Marillat maril...@free.fr wrote: Andres Mejia amejia...@gmail.com writes: [...] Also I upload my packages more quickly than Debian. 3.99.0, 3.99.1 3.99.2 lame version have never been packaged by Debian. Ok. Why not directly upload these packages to Debian then? You are still a Debian developer right? In case you didn't know, I'm part of the team packaging multimedia related software for Debian. I'm also a DD. I help maintain lame, x264, and a list of other packages in Debian. I could use help in keeping lame and other packages up to date. I don't have time to upload new releases right when they're released. Would you be willing to help maintain packages in Debian? This isn't possible to change the soname library monthly because the release team will probably reject monthly new soname. Also a new soname mean to rebuild all package who depends on the new soname library because the old soname packages are removed in Debian. We request library transitions in this case. Usually, the release team grants us these requests within a reasonable time frame. Here, I can keep more than one soname library. A nice example is Debian released a new -120 package the same day I did a -124 package. For x264, we're tracking the stable branch, currently at commit 01f7a33... You must be tracking master. In any case, Debian has experimental for these cases (providing a stable library package and an experimental one). You could be helping maintain x264 via unstable and experimental. [...] Also some pakcages like vlc or xine are in my repository because Debian added a conflicts against libavutil51 from my repository. [...] I looked at the packaging for vlc and xine-lib. I don't see a place where a conflicts to any libav/ffmpeg libraries was added. , | $ apt-cache show libpostproc52 | Package: libpostproc52 | Source: libav | Version: 4:0.8.1-1 | Installed-Size: 403 | Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org | Architecture: i386 | Depends: libavutil51 (= 4:0.8.1-1) | libavutil-extra-51 (= 4:0.8.1), libavutil51 ( 4:0.8.1-99) | libavutil-extra-51 ( 4:0.8.1.99), libc6 (= 2.4) ` Could you explain the libavutil51 ( 4:0.8.1-99) | libavutil-extra-51 ( 4:0.8.1.99) in Depends field ? You're looking at the strict dependencies set only for the libav packages. The shlibs is generated again so that the Depends field above does not apply to any packages depending on the libav libraries. See vlc for example. $ apt-cache show vlc Package: vlc Version: 2.0.0-6 Installed-Size: 3459 Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Architecture: amd64 Replaces: vlc-nox ( 1.1.5-1) Provides: mp3-decoder Depends: ttf-freefont, vlc-nox (= 2.0.0-6), libaa1 (= 1.4p5), libavcodec53 (= 4:0.8-1~) | libavcodec-extra-53 (= 4:0.8-1~), libavutil51 (= 4:0.8-1~) | libavutil-extra-51 (= 4:0.8-1~), libc6 (= 2.8), libfreetype6 (= 2.2.1), libfribidi0 (= 0.19.2), libgcc1 (= 1:4.1.1), libgl1-mesa-glx | libgl1, libice6 (= 1:1.0.0), libqtcore4 (= 4:4.7.0~beta1), libqtgui4 (= 4:4.7.0~beta1), libsdl-image1.2 (= 1.2.10), libsdl1.2debian (= 1.2.11), libsm6, libstdc++6 (= 4.6), libtar0, libva-x11-1 ( 1.0.14~), libva1 ( 1.0.14~), libvlccore5 (= 2.0.0), libx11-6, libxcb-composite0, libxcb-keysyms1 (= 0.3.8), libxcb-randr0 (= 1.1), libxcb-render0, libxcb-shape0, libxcb-shm0, libxcb-xfixes0, libxcb-xv0 (= 1.2), libxcb1 (= 1.6), libxext6, libxinerama1, libxpm4, zlib1g (= 1:1.2.3.3) Recommends: vlc-plugin-notify (= 2.0.0-6), vlc-plugin-pulse (= 2.0.0-6), xdg-utils Suggests: videolan-doc Breaks: vlc-nox ( 1.1.5-1) Description-en: multimedia player and streamer --- Speaking of libav/ffmpeg, the Debian archive has libav and not ffmpeg. I see that DMO is the reverse, shipping ffmpeg instead of libav. This of course resulted in many breakages between packages in Debian and packages in DMO. Which breakage ? Tell me what is exactly broken. Here are some of the more recent reported problems with using dmo. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663893 2. http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-March/025352.html # read the quoted message 3. http://lists.debian.org/debian-devel/2012/03/msg00129.html About 2 and 3, I can personally attest that this kind of breakage with using dmo does happen. Years ago when I first switched to Debian, I too thought that using dmo would be alright, seeing that it should only provide missing codecs and other software not available in Debian at the time. Long story short, after certain packages were upgraded because of dmo being activated on my system, I was left with numerous package conflicts and a missing desktop environment (in my case, kde
Re: Duplicate Packages from Debian archive in DMO
On Thu, Mar 22, 2012 at 9:45 AM, Stuart Prescott stu...@nanonanonano.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Andres, Thanks. This really helps. glad to be of assistance :) I was going to ask, could you do a query on sid showing the source packages available in dmo only and in both debian and dmo? I'm still waiting on the import of the udd to my system. The naive answer to this question would turn up source package names that are different between the Debian and dmo archives as dmo has been adding - dmo to source packages to distinguish them from the Debian variant. There would also be libav vs ffmpeg differences. So, I've not actually answered that question directly but instead some slightly different ones that I hope are what you really wanted to know: * What packages are in Debian and dmo that have the same name or have -'dmo added to them? (Note that ffmpeg-dmo and xbmc-dmo both exist without a non--dmo source package existing in Debian) Yes, this is what I wanted to know. * What source packages in dmo are building binary packages with the same package names as binary packages in Debian? * What source packages in dmo are building binary packages that are not in Debian? The third of these questions turns up: * packages like acroread that I guess will never be in Debian * various multimedia packages that might one day be in Debian * variations on multimedia packages that introduce extra binary packages (I guess ffmpeg-dmo producing libswresample* and mp4v2-dmo producing mp4-utils packages perhaps fall into this category) * boring soname changes on libraries like x264-dmo producing libx264-122 I suspect that sifting through these different cases probably requires a person with knowledge of the Debian packages rather than more SQL. Results (and SQL) attached. Let me know if there are further queries I can help with. cheers Stuart Thank you. - -- Stuart Prescott www.nanoNANOnano.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9rLPgACgkQn+i4zXHF0ait8ACdH1ufHnTR5X9v2GZp5NoMqGkZ BIMAn04BPp6WB/4tR6Rx/HGnbiXfyyXT =wYRo -END PGP 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 -- ~ Andres ___ 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#658084: libav-extra: Really necessary?
On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: On Wed, Mar 21, 2012 at 1:40 AM, Andres Mejia amejia...@gmail.com wrote: Here are some of the comments Reinhard said on IRC. Placing them here for recording purposes. [02:47] siretart amejia: in the merged case, I think the -dev packages can have tight dependencies on the library packages [02:48] siretart amejia: also, I think only libavcodec changes, so in that case we'd no longer need to provide e.g. libavutil-extra-51 [03:00] siretart amejia: ultimatively, I think this change goes into the right direction. unfortunately, it wont save a lot of effort, because for ubuntu we'll still need libav-extra and this change needs to be reverted there. at least for now :-( With only libavcodec having an extra package, the other extra packages would need transitional packages. Also, I'm afraid the epoch would need to be bumped again. $ dpkg --compare-versions 4:0.8.1-1 le 4:0.8.1.1 echo true true I would like to upload a package to experimental soon. Anyone have any other suggestions at this time? Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? -- regards, Reinhard Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? -- ~ Andres ___ 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: Duplicate Packages from Debian archive in DMO
FYI to all, here was Christian's response. Don't have time yet to fully respond, but I think keeping some packages there because they're not uploaded in Debian as quickly is not really a good reason to upload them or keep them uploaded at DMO. He's a DD and he could help to keep these packages updated in Debian instead (though this would mean he would have to work with the team). On Wed, Mar 21, 2012 at 2:26 AM, Christian Marillat maril...@free.fr wrote: Andres Mejia amejia...@gmail.com writes: Hi, Hi, This has been a question that's been asked in the debian-devel mailing list and among the Debian multimedia team recently. Why are packages already in the Debian archive still being uploaded to DMO? For example, there is lame, x264, and xvidcore which have been uploaded to the Debian archive, migrated to testing, and backported to the stable release. Yet I see that at least lame and x264 are still being updated in DMO. Is there any particular reason why? x264 isn't the same version libx264-122 here and -120 in Debian. Also I upload my packages more quickly than Debian. 3.99.0, 3.99.1 3.99.2 lame version have never been packaged by Debian. I'll certainly remove xvidcore. FYI each time a package enter Debian this package is removed from my repository, the latest is aegisub. Also some pakcages like vlc or xine are in my repository because Debian added a conflicts against libavutil51 from my repository. Christian -- ~ Andres ___ 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#658084: libav-extra: Really necessary?
On Mar 21, 2012 4:40 PM, Micah Gersten mic...@ubuntu.com wrote: On 03/21/2012 06:40 AM, Andres Mejia wrote: On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? libav can be demoted next cycle when KDE gets demoted to universe. Micah Great thanks. Reinhard, did you wanted 0.8.1 in precise? Betafreeze is tomorrow. ~ Andres ___ 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#658084: libav-extra: Really necessary?
On Wed, Mar 21, 2012 at 6:58 PM, Reinhard Tartler siret...@gmail.com wrote: On Wed, Mar 21, 2012 at 9:55 PM, Andres Mejia amejia...@gmail.com wrote: On Mar 21, 2012 4:40 PM, Micah Gersten mic...@ubuntu.com wrote: On 03/21/2012 06:40 AM, Andres Mejia wrote: On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? libav can be demoted next cycle when KDE gets demoted to universe. Micah Great thanks. Reinhard, did you wanted 0.8.1 in precise? Betafreeze is tomorrow. Thanks for the notice, yes I did, and unfortunately, I'm travelling and won't be at home before friday. Could anyone from the team please upload 0.8.1 to precise for me before the freeze? Thanks in advance! -- regards, Reinhard I'm not an Ubuntu developer I'm afraid. At best I could have something ready for someone to review and sponsor for an upload to Ubuntu. We could always ask for a freeze exception. After all, this new release brings a lot of security fixes. -- ~ Andres ___ 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: libav_0.8.1-2_amd64.changes ACCEPTED into experimental
Ok everyone. Feel free to starting testing the new libav packages. On Wed, Mar 21, 2012 at 6:33 PM, Debian FTP Masters ftpmas...@ftp-master.debian.org wrote: Accepted: ffmpeg-dbg_0.8.1-2_amd64.deb to main/liba/libav/ffmpeg-dbg_0.8.1-2_amd64.deb ffmpeg-doc_0.8.1-2_all.deb to main/liba/libav/ffmpeg-doc_0.8.1-2_all.deb ffmpeg_0.8.1-2_all.deb to main/liba/libav/ffmpeg_0.8.1-2_all.deb libav-dbg_0.8.1-2_amd64.deb to main/liba/libav/libav-dbg_0.8.1-2_amd64.deb libav-doc_0.8.1-2_all.deb to main/liba/libav/libav-doc_0.8.1-2_all.deb libav-extra-dbg_0.8.1-2_amd64.deb to main/liba/libav/libav-extra-dbg_0.8.1-2_amd64.deb libav-regular-dbg_0.8.1-2_amd64.deb to main/liba/libav/libav-regular-dbg_0.8.1-2_amd64.deb libav-tools_0.8.1-2_amd64.deb to main/liba/libav/libav-tools_0.8.1-2_amd64.deb libav_0.8.1-2.debian.tar.gz to main/liba/libav/libav_0.8.1-2.debian.tar.gz libav_0.8.1-2.dsc to main/liba/libav/libav_0.8.1-2.dsc libavcodec-dev_0.8.1-2_amd64.deb to main/liba/libav/libavcodec-dev_0.8.1-2_amd64.deb libavcodec-extra-53_0.8.1-2_amd64.deb to main/liba/libav/libavcodec-extra-53_0.8.1-2_amd64.deb libavcodec53_0.8.1-2_amd64.deb to main/liba/libav/libavcodec53_0.8.1-2_amd64.deb libavdevice-dev_0.8.1-2_amd64.deb to main/liba/libav/libavdevice-dev_0.8.1-2_amd64.deb libavdevice-extra-53_0.8.1-2_all.deb to main/liba/libav/libavdevice-extra-53_0.8.1-2_all.deb libavdevice53_0.8.1-2_amd64.deb to main/liba/libav/libavdevice53_0.8.1-2_amd64.deb libavfilter-dev_0.8.1-2_amd64.deb to main/liba/libav/libavfilter-dev_0.8.1-2_amd64.deb libavfilter-extra-2_0.8.1-2_all.deb to main/liba/libav/libavfilter-extra-2_0.8.1-2_all.deb libavfilter2_0.8.1-2_amd64.deb to main/liba/libav/libavfilter2_0.8.1-2_amd64.deb libavformat-dev_0.8.1-2_amd64.deb to main/liba/libav/libavformat-dev_0.8.1-2_amd64.deb libavformat-extra-53_0.8.1-2_all.deb to main/liba/libav/libavformat-extra-53_0.8.1-2_all.deb libavformat53_0.8.1-2_amd64.deb to main/liba/libav/libavformat53_0.8.1-2_amd64.deb libavutil-dev_0.8.1-2_amd64.deb to main/liba/libav/libavutil-dev_0.8.1-2_amd64.deb libavutil-extra-51_0.8.1-2_all.deb to main/liba/libav/libavutil-extra-51_0.8.1-2_all.deb libavutil51_0.8.1-2_amd64.deb to main/liba/libav/libavutil51_0.8.1-2_amd64.deb libpostproc-dev_0.8.1-2_amd64.deb to main/liba/libav/libpostproc-dev_0.8.1-2_amd64.deb libpostproc-extra-52_0.8.1-2_all.deb to main/liba/libav/libpostproc-extra-52_0.8.1-2_all.deb libpostproc52_0.8.1-2_amd64.deb to main/liba/libav/libpostproc52_0.8.1-2_amd64.deb libswscale-dev_0.8.1-2_amd64.deb to main/liba/libav/libswscale-dev_0.8.1-2_amd64.deb libswscale-extra-2_0.8.1-2_all.deb to main/liba/libav/libswscale-extra-2_0.8.1-2_all.deb libswscale2_0.8.1-2_amd64.deb to main/liba/libav/libswscale2_0.8.1-2_amd64.deb Changes: libav (5:0.8.1-2) experimental; urgency=low . [ Andres Mejia ] * Merge libav-extra packages to libav. (Closes: #658084) * Provide only libavcodec-extra package, the other packages are unnecessary. * Remove libav-source package. No longer necessary. * Remove dependencies and suggests of FAAD, no longer needed. * Set Enhances field and update package description for libavcodec-extra package. (Closes: #653451) * Fix issue with installation of debug symbols. (Closes: #642798) . [ Fabian Greffrath ] * Mention license impact in libavcodec-extra-53's package description. Override entries for your package: ffmpeg-dbg_0.8.1-2_amd64.deb - extra oldlibs ffmpeg-doc_0.8.1-2_all.deb - extra oldlibs ffmpeg_0.8.1-2_all.deb - extra oldlibs libav-dbg_0.8.1-2_amd64.deb - extra debug libav-doc_0.8.1-2_all.deb - optional doc libav-extra-dbg_0.8.1-2_amd64.deb - extra debug libav-regular-dbg_0.8.1-2_amd64.deb - extra debug libav-tools_0.8.1-2_amd64.deb - optional video libav_0.8.1-2.dsc - source libs libavcodec-dev_0.8.1-2_amd64.deb - optional libdevel libavcodec-extra-53_0.8.1-2_amd64.deb - optional libs libavcodec53_0.8.1-2_amd64.deb - optional libs libavdevice-dev_0.8.1-2_amd64.deb - optional libdevel libavdevice-extra-53_0.8.1-2_all.deb - optional libs libavdevice53_0.8.1-2_amd64.deb - optional libs libavfilter-dev_0.8.1-2_amd64.deb - optional libdevel libavfilter-extra-2_0.8.1-2_all.deb - optional libs libavfilter2_0.8.1-2_amd64.deb - optional libs libavformat-dev_0.8.1-2_amd64.deb - optional libdevel libavformat-extra-53_0.8.1-2_all.deb - optional libs libavformat53_0.8.1-2_amd64.deb - optional libs libavutil-dev_0.8.1-2_amd64.deb - optional libdevel libavutil-extra-51_0.8.1-2_all.deb - optional libs libavutil51_0.8.1-2_amd64.deb - optional libs libpostproc-dev_0.8.1-2_amd64.deb - optional libdevel libpostproc-extra-52_0.8.1-2_all.deb - optional libs libpostproc52_0.8.1-2_amd64.deb - optional libs libswscale-dev_0.8.1-2_amd64.deb - optional libdevel libswscale-extra-2_0.8.1-2_all.deb - optional libs libswscale2_0.8.1-2_amd64.deb - optional libs Announcing to debian-experimental
Re: libav_0.8.1-2_amd64.changes ACCEPTED into experimental
I should have worded that better. Testers wanted. Please help test the new libav packages. On Wed, Mar 21, 2012 at 7:40 PM, Andres Mejia amejia...@gmail.com wrote: Ok everyone. Feel free to starting testing the new libav packages. On Wed, Mar 21, 2012 at 6:33 PM, Debian FTP Masters ftpmas...@ftp-master.debian.org wrote: Accepted: ffmpeg-dbg_0.8.1-2_amd64.deb to main/liba/libav/ffmpeg-dbg_0.8.1-2_amd64.deb ffmpeg-doc_0.8.1-2_all.deb to main/liba/libav/ffmpeg-doc_0.8.1-2_all.deb ffmpeg_0.8.1-2_all.deb to main/liba/libav/ffmpeg_0.8.1-2_all.deb libav-dbg_0.8.1-2_amd64.deb to main/liba/libav/libav-dbg_0.8.1-2_amd64.deb libav-doc_0.8.1-2_all.deb to main/liba/libav/libav-doc_0.8.1-2_all.deb libav-extra-dbg_0.8.1-2_amd64.deb to main/liba/libav/libav-extra-dbg_0.8.1-2_amd64.deb libav-regular-dbg_0.8.1-2_amd64.deb to main/liba/libav/libav-regular-dbg_0.8.1-2_amd64.deb libav-tools_0.8.1-2_amd64.deb to main/liba/libav/libav-tools_0.8.1-2_amd64.deb libav_0.8.1-2.debian.tar.gz to main/liba/libav/libav_0.8.1-2.debian.tar.gz libav_0.8.1-2.dsc to main/liba/libav/libav_0.8.1-2.dsc libavcodec-dev_0.8.1-2_amd64.deb to main/liba/libav/libavcodec-dev_0.8.1-2_amd64.deb libavcodec-extra-53_0.8.1-2_amd64.deb to main/liba/libav/libavcodec-extra-53_0.8.1-2_amd64.deb libavcodec53_0.8.1-2_amd64.deb to main/liba/libav/libavcodec53_0.8.1-2_amd64.deb libavdevice-dev_0.8.1-2_amd64.deb to main/liba/libav/libavdevice-dev_0.8.1-2_amd64.deb libavdevice-extra-53_0.8.1-2_all.deb to main/liba/libav/libavdevice-extra-53_0.8.1-2_all.deb libavdevice53_0.8.1-2_amd64.deb to main/liba/libav/libavdevice53_0.8.1-2_amd64.deb libavfilter-dev_0.8.1-2_amd64.deb to main/liba/libav/libavfilter-dev_0.8.1-2_amd64.deb libavfilter-extra-2_0.8.1-2_all.deb to main/liba/libav/libavfilter-extra-2_0.8.1-2_all.deb libavfilter2_0.8.1-2_amd64.deb to main/liba/libav/libavfilter2_0.8.1-2_amd64.deb libavformat-dev_0.8.1-2_amd64.deb to main/liba/libav/libavformat-dev_0.8.1-2_amd64.deb libavformat-extra-53_0.8.1-2_all.deb to main/liba/libav/libavformat-extra-53_0.8.1-2_all.deb libavformat53_0.8.1-2_amd64.deb to main/liba/libav/libavformat53_0.8.1-2_amd64.deb libavutil-dev_0.8.1-2_amd64.deb to main/liba/libav/libavutil-dev_0.8.1-2_amd64.deb libavutil-extra-51_0.8.1-2_all.deb to main/liba/libav/libavutil-extra-51_0.8.1-2_all.deb libavutil51_0.8.1-2_amd64.deb to main/liba/libav/libavutil51_0.8.1-2_amd64.deb libpostproc-dev_0.8.1-2_amd64.deb to main/liba/libav/libpostproc-dev_0.8.1-2_amd64.deb libpostproc-extra-52_0.8.1-2_all.deb to main/liba/libav/libpostproc-extra-52_0.8.1-2_all.deb libpostproc52_0.8.1-2_amd64.deb to main/liba/libav/libpostproc52_0.8.1-2_amd64.deb libswscale-dev_0.8.1-2_amd64.deb to main/liba/libav/libswscale-dev_0.8.1-2_amd64.deb libswscale-extra-2_0.8.1-2_all.deb to main/liba/libav/libswscale-extra-2_0.8.1-2_all.deb libswscale2_0.8.1-2_amd64.deb to main/liba/libav/libswscale2_0.8.1-2_amd64.deb Changes: libav (5:0.8.1-2) experimental; urgency=low . [ Andres Mejia ] * Merge libav-extra packages to libav. (Closes: #658084) * Provide only libavcodec-extra package, the other packages are unnecessary. * Remove libav-source package. No longer necessary. * Remove dependencies and suggests of FAAD, no longer needed. * Set Enhances field and update package description for libavcodec-extra package. (Closes: #653451) * Fix issue with installation of debug symbols. (Closes: #642798) . [ Fabian Greffrath ] * Mention license impact in libavcodec-extra-53's package description. Override entries for your package: ffmpeg-dbg_0.8.1-2_amd64.deb - extra oldlibs ffmpeg-doc_0.8.1-2_all.deb - extra oldlibs ffmpeg_0.8.1-2_all.deb - extra oldlibs libav-dbg_0.8.1-2_amd64.deb - extra debug libav-doc_0.8.1-2_all.deb - optional doc libav-extra-dbg_0.8.1-2_amd64.deb - extra debug libav-regular-dbg_0.8.1-2_amd64.deb - extra debug libav-tools_0.8.1-2_amd64.deb - optional video libav_0.8.1-2.dsc - source libs libavcodec-dev_0.8.1-2_amd64.deb - optional libdevel libavcodec-extra-53_0.8.1-2_amd64.deb - optional libs libavcodec53_0.8.1-2_amd64.deb - optional libs libavdevice-dev_0.8.1-2_amd64.deb - optional libdevel libavdevice-extra-53_0.8.1-2_all.deb - optional libs libavdevice53_0.8.1-2_amd64.deb - optional libs libavfilter-dev_0.8.1-2_amd64.deb - optional libdevel libavfilter-extra-2_0.8.1-2_all.deb - optional libs libavfilter2_0.8.1-2_amd64.deb - optional libs libavformat-dev_0.8.1-2_amd64.deb - optional libdevel libavformat-extra-53_0.8.1-2_all.deb - optional libs libavformat53_0.8.1-2_amd64.deb - optional libs libavutil-dev_0.8.1-2_amd64.deb - optional libdevel libavutil-extra-51_0.8.1-2_all.deb - optional libs libavutil51_0.8.1-2_amd64.deb - optional libs libpostproc-dev_0.8.1-2_amd64.deb - optional libdevel libpostproc-extra-52_0.8.1-2_all.deb - optional libs libpostproc52_0.8.1-2_amd64.deb - optional libs libswscale
Re: Duplicate Packages from Debian archive in DMO
On Wed, Mar 21, 2012 at 7:11 PM, Stuart Prescott stu...@nanonanonano.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Just to put some real data on packages that are in both Debian and debian-multimedia.org I extracted the appended data from UDD. I suspect that many will find inclusion of packages like libdrm-intel1 and libdrm2 somewhat beyond the multimedia calling of this repository. In terms of shear size of the repository: release | binary_packages | source_packages - +-+- sid-multimedia | 298 | 128 wheezy-multimedia | 306 | 134 squeeze-multimedia | 331 | 151 lenny-multimedia | 256 | 120 which is certainly consistent with the feedback that packages are dropped from dmm as they become available in Debian and that the position is much better for wheezy than squeeze. Please feel free to let me know if there is further data from UDD that would be useful here. cheers Stuart Squeeze: package | debian_version | dmm_version - +--+ audacity | 1.3.12-6 | 1.3.12-7.4 audacity-data | 1.3.12-6 | 1.3.12-7.4 audacity-dbg | 1.3.12-6 | 1.3.12-7.4 blender | 2.49.2~dfsg-2+b2 | 2.49.2~dfsg-2.1 dir2ogg | 0.11.8-1 | 0.9.3-0.0 ffmpeg | 4:0.5.6-3 | 5:0.7.11-0.1 ffmpeg-dbg | 4:0.5.6-3 | 5:0.7.11-0.1 ffmpeg-doc | 4:0.5.6-3 | 5:0.7.11-0.1 i965-va-driver | 1.0.1-3 | 1.0.7-0.0 icecast2 | 2.3.2-6 | 1:2.3.2kh29-0.4squeeze1 kdenlive | 0.7.8-1 | 0.7.8-1.2 kdenlive-data | 0.7.8-1 | 0.7.8-1.2 kdenlive-dbg | 0.7.8-1 | 0.7.8-1.2 libavcodec52 | 4:0.5.6-3 | 5:0.7.11-0.1 libavcodec-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libavdevice52 | 4:0.5.6-3 | 5:0.7.11-0.1 libavdevice-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libavfilter-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libavformat52 | 4:0.5.6-3 | 5:0.7.11-0.1 libavformat-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libavutil-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libdrm2 | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm2-dbg | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-dev | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-intel1 | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-intel1-dbg | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-radeon1 | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-radeon1-dbg | 2.4.21-1~squeeze3 | 2.4.23-0.0 libmlt++3 | 0.5.6+git20100727-1 | 1:0.6.2-0.0 libmlt-data | 0.5.6+git20100727-1 | 1:0.6.2-0.0 libmlt-dev | 0.5.6+git20100727-1 | 1:0.6.2-0.0 libmlt++-dev | 0.5.6+git20100727-1 | 1:0.6.2-0.0 libpostproc51 | 4:0.5.6-3 | 5:0.7.11-0.1 libpostproc-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libquicktime1 | 2:1.1.5-1+b1 | 3:1.2.2-0.3squeeze1 libquicktime-dev | 2:1.1.5-1+b1 | 3:1.2.2-0.3squeeze1 libquicktime-doc | 2:1.1.5-1 | 3:1.2.2-0.3squeeze1 libswscale0 | 4:0.5.6-3 | 5:0.7.11-0.1 libswscale-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libva1 | 1.0.1-3 | 1.0.7-0.0 libva-dev | 1.0.1-3 | 1.0.7-0.0 libva-x11-1 | 1.0.1-3 | 1.0.7-0.0 libvpx0 | 0.9.1-2 | 0.9.7.p1-2.squeeze2 libvpx0-dbg | 0.9.1-2 | 0.9.7.p1-2.squeeze2 libvpx-dev | 0.9.1-2 | 0.9.7.p1-2.squeeze2 libvpx-doc | 0.9.1-2 | 0.9.7.p1-2.squeeze2 melt | 0.5.6+git20100727-1 | 1:0.6.2-0.0 mencoder | 2:1.0~rc3++final.dfsg1-1 | 2:1.0~rc3++svn20100804-0.2squeeze1 mplayer | 2:1.0~rc3++final.dfsg1-1 | 2:1.0~rc3++svn20100804-0.2squeeze1 mplayer-doc | 2:1.0~rc3++final.dfsg1-1 | 2:1.0~rc3++svn20100804-0.2squeeze1 quicktime-utils | 2:1.1.5-1+b1 | 3:1.2.2-0.3squeeze1 quicktime-x11utils | 2:1.1.5-1+b1 | 3:1.2.2-0.3squeeze1 vainfo | 1.0.1-3 | 1.0.7-0.0 (53 rows) Sid: package | debian_version | dmm_version - --+---+- ffmpeg-dbg | 4:0.8.1-1 | 5:0.10.2-0.0 ffmpeg-doc
Re: new version of package 'crtmpserver' was prepared
2012/3/21 Andriy Beregovenko j...@jet.kiev.ua: Hi, I finished update package 'crtmpserver'. This is major update from the point of view of upstream update, but debian package changes are insignificant. So, please, upload updated version of package. -- Best regards, Andriy 0xBDDBDAE3 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJPalsqAAoJEDajjCG929rjtDwP/1P3zn2r6VyKMA4LIx9h4OK9 JUyaf67iumAURLoY6Ndl7mxHdUexk8GMI5cTPrGwiQNY4TqzU8BxSoOaBdoWrbPZ kfDx5R0yhL3bT8xRRqOSxckV5Qvy/lStn/SyFmUN1WQ5GpMqv8Uss528yiPbuIhg jNm45XrzCmPNf9m3jNRtAIkA8YyVxiIFnBEvczXP5e//N8kQ2lmHGF8i8SKJi/gU cKiDvbmGYEhJjnHfO7XOOJk5R6YPJMF/Hf3D3q5avkdojUx+zbgJCY6AD5BJzqGM AehVHD8QK/YnToP3WGeXwIIVCaO6eVLxSkRzqwvdxJbmyPnYSnlVOm0Vgt3WRxkR lY8xtXXwZi24XOVfdWEShYjioMFdwwXPmpRYESjU2g3PpKaKG+NXWhhjjyqqxYfe pr6Fb5Pl6lGnxbkVpIL+Mb3n5sOOPvMh+MgJXy6kWuDmgS8ssn2M+/xtRd0jFAaa zJYipwSVJYsWj1TsMNC8ptCcDM2l81cLUMwbWSQQpjcUDHMhfOPJ4TPr1Ncz6kPM DjqVi1sZoXSBmlxHh1xwWUXDdenZfwFHlD5SmgdkTE3sJhjk1v7y60/J4XOcFv4U waXS6kLL2ZcE3tlDEWeznUOqkKMvaY7WogCspMSRyrO2IGAsLRaLzkmyBs6utDNC PI/5g3UYIjevkrBa28vL =a6DZ -END PGP 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 Ok, uploaded. -- ~ Andres ___ 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: Duplicate Packages from Debian archive in DMO
On Wed, Mar 21, 2012 at 8:42 PM, Andres Mejia amejia...@gmail.com wrote: On Wed, Mar 21, 2012 at 7:11 PM, Stuart Prescott stu...@nanonanonano.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Just to put some real data on packages that are in both Debian and debian-multimedia.org I extracted the appended data from UDD. I suspect that many will find inclusion of packages like libdrm-intel1 and libdrm2 somewhat beyond the multimedia calling of this repository. In terms of shear size of the repository: release | binary_packages | source_packages - +-+- sid-multimedia | 298 | 128 wheezy-multimedia | 306 | 134 squeeze-multimedia | 331 | 151 lenny-multimedia | 256 | 120 which is certainly consistent with the feedback that packages are dropped from dmm as they become available in Debian and that the position is much better for wheezy than squeeze. Please feel free to let me know if there is further data from UDD that would be useful here. cheers Stuart Squeeze: package | debian_version | dmm_version - +--+ audacity | 1.3.12-6 | 1.3.12-7.4 audacity-data | 1.3.12-6 | 1.3.12-7.4 audacity-dbg | 1.3.12-6 | 1.3.12-7.4 blender | 2.49.2~dfsg-2+b2 | 2.49.2~dfsg-2.1 dir2ogg | 0.11.8-1 | 0.9.3-0.0 ffmpeg | 4:0.5.6-3 | 5:0.7.11-0.1 ffmpeg-dbg | 4:0.5.6-3 | 5:0.7.11-0.1 ffmpeg-doc | 4:0.5.6-3 | 5:0.7.11-0.1 i965-va-driver | 1.0.1-3 | 1.0.7-0.0 icecast2 | 2.3.2-6 | 1:2.3.2kh29-0.4squeeze1 kdenlive | 0.7.8-1 | 0.7.8-1.2 kdenlive-data | 0.7.8-1 | 0.7.8-1.2 kdenlive-dbg | 0.7.8-1 | 0.7.8-1.2 libavcodec52 | 4:0.5.6-3 | 5:0.7.11-0.1 libavcodec-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libavdevice52 | 4:0.5.6-3 | 5:0.7.11-0.1 libavdevice-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libavfilter-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libavformat52 | 4:0.5.6-3 | 5:0.7.11-0.1 libavformat-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libavutil-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libdrm2 | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm2-dbg | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-dev | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-intel1 | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-intel1-dbg | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-radeon1 | 2.4.21-1~squeeze3 | 2.4.23-0.0 libdrm-radeon1-dbg | 2.4.21-1~squeeze3 | 2.4.23-0.0 libmlt++3 | 0.5.6+git20100727-1 | 1:0.6.2-0.0 libmlt-data | 0.5.6+git20100727-1 | 1:0.6.2-0.0 libmlt-dev | 0.5.6+git20100727-1 | 1:0.6.2-0.0 libmlt++-dev | 0.5.6+git20100727-1 | 1:0.6.2-0.0 libpostproc51 | 4:0.5.6-3 | 5:0.7.11-0.1 libpostproc-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libquicktime1 | 2:1.1.5-1+b1 | 3:1.2.2-0.3squeeze1 libquicktime-dev | 2:1.1.5-1+b1 | 3:1.2.2-0.3squeeze1 libquicktime-doc | 2:1.1.5-1 | 3:1.2.2-0.3squeeze1 libswscale0 | 4:0.5.6-3 | 5:0.7.11-0.1 libswscale-dev | 4:0.5.6-3 | 5:0.7.11-0.1 libva1 | 1.0.1-3 | 1.0.7-0.0 libva-dev | 1.0.1-3 | 1.0.7-0.0 libva-x11-1 | 1.0.1-3 | 1.0.7-0.0 libvpx0 | 0.9.1-2 | 0.9.7.p1-2.squeeze2 libvpx0-dbg | 0.9.1-2 | 0.9.7.p1-2.squeeze2 libvpx-dev | 0.9.1-2 | 0.9.7.p1-2.squeeze2 libvpx-doc | 0.9.1-2 | 0.9.7.p1-2.squeeze2 melt | 0.5.6+git20100727-1 | 1:0.6.2-0.0 mencoder | 2:1.0~rc3++final.dfsg1-1 | 2:1.0~rc3++svn20100804-0.2squeeze1 mplayer | 2:1.0~rc3++final.dfsg1-1 | 2:1.0~rc3++svn20100804-0.2squeeze1 mplayer-doc | 2:1.0~rc3++final.dfsg1-1 | 2:1.0~rc3++svn20100804-0.2squeeze1 quicktime-utils | 2:1.1.5-1+b1 | 3:1.2.2-0.3squeeze1 quicktime-x11utils | 2:1.1.5-1+b1 | 3:1.2.2-0.3squeeze1 vainfo | 1.0.1-3 | 1.0.7-0.0 (53 rows) Sid: package | debian_version | dmm_version - --+---+- ffmpeg-dbg
Bug#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
On Mon, Mar 19, 2012 at 9:55 PM, Andres Mejia amejia...@gmail.com wrote: On Mon, Mar 19, 2012 at 8:38 PM, Andreas Beckmann deb...@abeckmann.de wrote: Package: libva1 Version: 1.0.15-4 Severity: normal Hi, please use a search path for the DRI modules that contains both /usr/lib/triplet/dri /usr/lib/dri While we can (hopefully) fix the Debian packages to ship the files in the multiarch locations, the multiarch move breaks any third-party (probably proprietary) software/installer/... that is not multiarch aware. Therefore plugins should be searched in both locations. So far the following problems have been reported: xvba-va: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664487 fglrx + vainfo: $ vainfo libva: VA-API version 0.32.0 Xlib: extension XFree86-DRI missing on display :0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit I'm not sure if I can move dri/fglrx_drv_video.so around - it is loaded from the fglrx driver (a non-free blob) using the hardcoded path /usr/lib/dri ... (and the last time I tried to use symlinks (although in a different context) the fglrx blob used lstat() and complained about world writable files ...) Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers I don't believe modules should be allowed to load from /usr/lib/dri in a multiarch library. Suppose the amd64 library package is loaded into an i386 machine, and the module is i386 and installed in /usr/lib/dri. This configuration may cause breakage. I'm afraid the module has to be fixed, even if it's a proprietary module. -- ~ Andres I looked into this some more. NVIDIA's vdpau driver doesn't show a problem with the modules being installed in /usr/lib/x86_64-linux-gnu/vdpau. vainfo is working fine for me (after fixing some issues with the vdpau-va-driver which I just uploaded). $ vainfo libva: VA-API version 0.32.0 Xlib: extension XFree86-DRI missing on display :0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so libva: va_openDriver() returns 0 vainfo: VA-API version: 0.32 (libva 1.0.15) vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.3 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD Also, I checked the code that sets the module directory for both libvdpau and libva. Only one path is set for both libraries and it is based off of $libdir variable from their build systems. With multiarch, each library sets the module path to /usr/lib/triplet/*. With this information, I believe the fglrx driver should be fixed. -- ~ Andres ___ 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#658084: libav-extra: Really necessary?
Here are some of the comments Reinhard said on IRC. Placing them here for recording purposes. [02:47] siretart amejia: in the merged case, I think the -dev packages can have tight dependencies on the library packages [02:48] siretart amejia: also, I think only libavcodec changes, so in that case we'd no longer need to provide e.g. libavutil-extra-51 [03:00] siretart amejia: ultimatively, I think this change goes into the right direction. unfortunately, it wont save a lot of effort, because for ubuntu we'll still need libav-extra and this change needs to be reverted there. at least for now :-( With only libavcodec having an extra package, the other extra packages would need transitional packages. Also, I'm afraid the epoch would need to be bumped again. $ dpkg --compare-versions 4:0.8.1-1 le 4:0.8.1.1 echo true true I would like to upload a package to experimental soon. Anyone have any other suggestions at this time? -- ~ Andres ___ 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#664819: libav source build needs to link with -lgcrypt
On Tue, Mar 20, 2012 at 9:24 PM, Dave Anglin dave.ang...@bell.net wrote: Source: libav Version: 4:0.8.1-1 Severity: normal gcc -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavutil -Llibpostproc -Llibswscale -Wl,--as-needed -Wl,--warn-common -Wl,-rpath-link=libpostproc:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil -o ffmpeg ff mpeg.o cmdutils.o -lavdevice -lavfilter -lavformat -lavcodec -lpostproc -lswscale -lavutil -ldl -lX11 -lXext -lXfixes -lcdio_paranoia -lcdio_cdda -lcdio -ljack -lasound -ldc1394 -lraw1394 -lxvidcore -lx264 -lvpx -lvpx -lvorbisenc -lvorbis -logg -ltheoraenc -ltheoradec -logg -lspeex -lschroedinger-1.0 -lrtmp -lz -lgnutl s -lpulse-simple -lpulse -lopenjpeg -lopencv_core -lopencv_imgproc -lopencv_high gui -lopencv_ml -lopencv_video -lopencv_features2d -lopencv_calib3d -lopencv_obj detect -lopencv_contrib -lopencv_legacy -lopencv_flann -lmp3lame -lgsm -lfreetyp e -ldirac_encoder -ldirac_decoder -lstdc++ -lgnutls -lva -lm -pthread -lbz2 -lz /usr/bin/ld.bfd.real: libavformat/libavformat.a(network.o): undefined reference to symbol 'gcry_control@@GCRYPT_1.2' /usr/bin/ld.bfd.real: note: 'gcry_control@@GCRYPT_1.2' is defined in DSO /lib/li bgcrypt.so.11 so try adding it to the linker command line /lib/libgcrypt.so.11: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[1]: *** [ffmpeg] Error 1 make[1]: Leaving directory `/home/dave/debian/libav/libav-0.8.1/debian-static' make: *** [build-stamp-static] Error 2 The following allows a successful build: --- rules.save 2012-03-18 14:40:11.0 -0400 +++ rules 2012-03-20 19:08:22.0 -0400 @@ -46,6 +46,7 @@ dh_testdir mkdir -p debian-$* cd debian-$* CFLAGS=$(CFLAGS) CPPFLAGS=$(CPPFLAGS) LDFLAGS=$(LDFLAGS) $(CURDIR)/configure \ + --extra-libs=-lgcrypt \ $($*_build_confflags) $(extra_$*_build_confflags) touch $@ -- System Information: Debian Release: wheezy/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 3.2.11+ (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers libav builds fine. See [1]. This issue is common if you're using the libav-extra libraries. It's likely a broken symlink from your *.so files. 1. https://buildd.debian.org/status/package.php?p=libav -- ~ Andres ___ 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#658084: libav-extra: Really necessary?
Ok, here are the changes to libav to include libav-extra so far. Just tested these and they provide a smooth upgrade with libav/libav-extra packages currently in unstable. avconv can use either libavcodec or libavcodec-extra package and it works like it should. None of the other packages were necessary as far as I can tell. Also, libav-source will be dropped. If nobody has any other suggestions, I would like to upload this to experimental for further testing. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Duplicate Packages from Debian archive in DMO
Hi, This has been a question that's been asked in the debian-devel mailing list and among the Debian multimedia team recently. Why are packages already in the Debian archive still being uploaded to DMO? For example, there is lame, x264, and xvidcore which have been uploaded to the Debian archive, migrated to testing, and backported to the stable release. Yet I see that at least lame and x264 are still being updated in DMO. Is there any particular reason why? -- ~ Andres ___ 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: x264_0.120.2171+git01f7a33-2_amd64.changes ACCEPTED into unstable
On Mon, Mar 19, 2012 at 4:48 AM, Fabian Greffrath fab...@greffrath.com wrote: Hi Andres, Am 17.03.2012 18:48, schrieb Debian FTP Masters: * Add hardened build flags excluding -O2 and -g. I don't quite get it. These packages already have dh compat 9 enabled and thus have the hardeneing build flags exported into their build environment. Why do you now explicitely set CFLAGS again, and while at it, ignore CPPFLAGS and LDFLAGS? - 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 x264 set -O3 by default. Us setting -O2 would have overridden that. And with -g, x264 doesn't set -g by default (I presume because full optimizations are enabled). Even so, x264 doesn't provide dbg packages so there's no use in enabling -g anyway. -- ~ Andres ___ 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: libdvdcss-installer - Package to install libdvdcss
On Mon, Mar 19, 2012 at 4:58 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 18.03.2012 00:42, schrieb Andres Mejia: libdvdcss-installer can be found at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libdvdcss-installer.git Any comments/concerns? I like the idea behind this script and as writing it was on my TODO list anyway, I like the fact that you actually started writing it first. ;) However, I see a problem in callign apt-get in the uninstall_libdvdcss() function and then calling libdvdcss-installer --remove in the prerm script. This will run apt-get while apt-get is still be active and thus might lead to confusion/fail. Ah yes, this needs to be changed. Furthermore, I think the first three checks in check_libdvdcss() are pretty redundant. We should only check if libdvdcss.so.2 is in LD_LIBRARY_PATH. If it isn't there, it's invisible to the dynamic linker anyway. LD_LIBRARY_PATH is not set on a default Debian system, hence why the other checks exist. Apart from this, good job. ;) Thanks. - Fabiam ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- ~ Andres ___ 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#658084: libav-extra: Really necessary?
On Mon, Mar 19, 2012 at 5:25 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.03.2012 03:59, schrieb Andres Mejia: Though the build time is increased for libav, ultimately, this change would be better as the buildd network would not have to cope with building from two source packages (i.e. setting up and tearing down for libav and libav-extra for each architecture). Also, in my opinion, it is easier and less error prone to maintain a single libav package rather than two of them. I generally agree with your proposal, although easier and less error-prone is in the eye of the beholder, of course. At least I am currently a bit lost in your proposed diff against debian/rules. ;) In this context, please remove the libav-source binary package as well. It is of no further use (that I know of) if the libav-extra source package is removed. Also, please make sure that only the dynamic libraries are rebuilt for the extra packages, not the static one (don't know if it is already like this; as I said, the diff is a bit too much for me on a Monday morning ;) ). - Fabian I think the libav-source package will still be useful. There are people who like to activate/deactivate certain features of libav. They can use the libav-source package and ensure they have a build with all the patches applied for the Debian builds of libav. -- ~ Andres ___ 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: [SCM] libdvdcss/master: Update changelog.
On Mon, Mar 19, 2012 at 9:03 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.03.2012 13:53, schrieb Jonas Smedegaard: Should stable be supported? I think so, but not necessarily without minor changes to the packaging. A package with minor adaption on backports.d.o would be sufficient IMHO. We should concentrate on unstable as our main development platform. - Fabian I believe stable should definitely be supported. -- ~ Andres ___ 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#658084: libav-extra: Really necessary?
On Mon, Mar 19, 2012 at 9:14 AM, Jonas Smedegaard d...@jones.dk wrote: On 12-03-19 at 08:59am, Andres Mejia wrote: On Mon, Mar 19, 2012 at 5:25 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.03.2012 03:59, schrieb Andres Mejia: Though the build time is increased for libav, ultimately, this change would be better as the buildd network would not have to cope with building from two source packages (i.e. setting up and tearing down for libav and libav-extra for each architecture). Also, in my opinion, it is easier and less error prone to maintain a single libav package rather than two of them. I generally agree with your proposal, although easier and less error-prone is in the eye of the beholder, of course. At least I am currently a bit lost in your proposed diff against debian/rules. ;) In this context, please remove the libav-source binary package as well. It is of no further use (that I know of) if the libav-extra source package is removed. Also, please make sure that only the dynamic libraries are rebuilt for the extra packages, not the static one (don't know if it is already like this; as I said, the diff is a bit too much for me on a Monday morning ;) ). I think the libav-source package will still be useful. There are people who like to activate/deactivate certain features of libav. They can use the libav-source package and ensure they have a build with all the patches applied for the Debian builds of libav. I disagree: That argument would apply for *any* package in Debian. Binary packages containing sources is a special construct specifically for our build system, not needed for direct exposure to our users: Users who want to recompile packages can much easier do so by forking the source package. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers Yes, after thinking about it, I was going to draw the same conclusion. Since the libav-extra package would no longer be needed, the libav-source package should go away. Users needing a different installation of libav libs can simply download the source package and recompile with whatever options they needed. -- ~ Andres ___ 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: x264_0.120.2171+git01f7a33-2_amd64.changes ACCEPTED into unstable
On Mon, Mar 19, 2012 at 9:40 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.03.2012 13:41, schrieb Andres Mejia: x264 set -O3 by default. Us setting -O2 would have overridden that. And with -g, x264 doesn't set -g by default (I presume because full optimizations are enabled). Even so, x264 doesn't provide dbg packages so there's no use in enabling -g anyway. I see, so you re-set CFLAGS to get rid of certain flags that are enabled in Debian by default but that the source's build system should better take care of in these cases. Is this right also for the other packages where you introduced this change? - 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 Yes. In particular, I checked if the package's build system sets -O3 instead of -O2. -- ~ Andres ___ 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#658084: libav-extra: Really necessary?
On Mon, Mar 19, 2012 at 9:52 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.03.2012 14:38, schrieb Andres Mejia: I made the changes to filter out building of static libs for extra packages. See [1]. Note that I rebased the changes from current master, so if you checked out this branch, you'll have to merge the changes back in. Alright. In this context, has someone lately tried out if the static libs that we provide in the -dev packages work at all? Yes, and they do. -- ~ Andres ___ 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: libdvdcss-installer - Package to install libdvdcss
On Mon, Mar 19, 2012 at 10:23 AM, Benjamin Drung bdr...@debian.org wrote: Am Samstag, den 17.03.2012, 19:42 -0400 schrieb Andres Mejia: On Sat, Mar 17, 2012 at 7:32 PM, ceros-gu...@users.alioth.debian.org wrote: The branch, master has been created at c4c77bca931e1dd7e0cce072985e694fcd5bb2e4 (commit) - Shortlog commit c4c77bca931e1dd7e0cce072985e694fcd5bb2e4 Author: Andres Mejia amejia...@gmail.com Date: Sat Mar 17 19:29:40 2012 -0400 Create new package for libdvdcss-installer. --- -- libdvdcss-installer packaging ___ pkg-multimedia-commits mailing list pkg-multimedia-comm...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-commits Ok, here was my idea of an installer for libdvdcss. This is it's very own package that can be installed via apt (i.e. apt-get install libdvdcss-installer). Through maintainer scripts, it can install, remove, and purge libdvdcss whenever the installer is installed, removed, and purged. I got this idea from a package I use to maintain long ago (nvidia-cg-toolkit) which works in similar fashion. My idea was to upload this to Debian contrib. If it failed to get accepted still, the script itself can be installed and used along with libdvdread instead. Maintainer scripts could be setup for libdvdread to automatically install/remove/purge libdvdcss, though the issue here is that libdvdread is in main. libdvdread must not depend on libdvdcss being available at all. libdvdcss-installer can be found at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libdvdcss-installer.git Any comments/concerns? Are we allowed to distribute the source code of libdvdcss? Then we could put the source code into a binary package and build it on installation. I would prefer a builder instead of distributing a downloader + builder. It would help to know why it was rejected in the first place. See [1]. Did anyone ever get that email that Joerg mentioned in the reject notification? 1. http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2011-July/020544.html -- ~ Andres ___ 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#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
On Mon, Mar 19, 2012 at 8:38 PM, Andreas Beckmann deb...@abeckmann.de wrote: Package: libva1 Version: 1.0.15-4 Severity: normal Hi, please use a search path for the DRI modules that contains both /usr/lib/triplet/dri /usr/lib/dri While we can (hopefully) fix the Debian packages to ship the files in the multiarch locations, the multiarch move breaks any third-party (probably proprietary) software/installer/... that is not multiarch aware. Therefore plugins should be searched in both locations. So far the following problems have been reported: xvba-va: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664487 fglrx + vainfo: $ vainfo libva: VA-API version 0.32.0 Xlib: extension XFree86-DRI missing on display :0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit I'm not sure if I can move dri/fglrx_drv_video.so around - it is loaded from the fglrx driver (a non-free blob) using the hardcoded path /usr/lib/dri ... (and the last time I tried to use symlinks (although in a different context) the fglrx blob used lstat() and complained about world writable files ...) Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers I don't believe modules should be allowed to load from /usr/lib/dri in a multiarch library. Suppose the amd64 library package is loaded into an i386 machine, and the module is i386 and installed in /usr/lib/dri. This configuration may cause breakage. I'm afraid the module has to be fixed, even if it's a proprietary module. -- ~ Andres ___ 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: [SCM] libdvdcss/master: Update changelog.
On Sun, Mar 18, 2012 at 12:09 PM, Jonas Smedegaard d...@jones.dk wrote: On 12-03-17 at 02:49pm, Andres Mejia wrote: That pretty much means libdvdcss can be compiled on Debian down to old-stable (if backports is used) and Ubuntu oneiric. For supporting Ubuntu suites before oneiric, we could use a seperate branch and modify the install-css.sh script accordingly. backports.debian.org is a *specific* add-on branch. Relying in backports.d.o really means that the package does *not* support backporting to oldstable+backports (not plain oldstable). Some (myself included) choose to locally backport _instead_ of mixing with backports.d.o. The package can be made to truly support backporting to pure oldstable using CDBS. I'd be happy to do that (or guide on how to do it), if that is of any interest. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers That's ok, was going to mention this will only work down to stable+backports and Ubuntu oneiric. I changed to debhelper (= 8.1.3~) to support multiarch. Should oldstable be supported? -- ~ Andres ___ 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: [SCM] libdvdcss/master: Update changelog.
On Sun, Mar 18, 2012 at 12:43 PM, Jonas Smedegaard d...@jones.dk wrote: On 12-03-18 at 12:22pm, Andres Mejia wrote: On Sun, Mar 18, 2012 at 12:09 PM, Jonas Smedegaard d...@jones.dk wrote: On 12-03-17 at 02:49pm, Andres Mejia wrote: That pretty much means libdvdcss can be compiled on Debian down to old-stable (if backports is used) and Ubuntu oneiric. For supporting Ubuntu suites before oneiric, we could use a seperate branch and modify the install-css.sh script accordingly. backports.debian.org is a *specific* add-on branch. Relying in backports.d.o really means that the package does *not* support backporting to oldstable+backports (not plain oldstable). Some (myself included) choose to locally backport _instead_ of mixing with backports.d.o. The package can be made to truly support backporting to pure oldstable using CDBS. I'd be happy to do that (or guide on how to do it), if that is of any interest. [snip] That's ok, was going to mention this will only work down to stable+backports and Ubuntu oneiric. I changed to debhelper (= 8.1.3~) to support multiarch. Should oldstable be supported? You answer a question with a question :-) When you initially wrote that's ok above, did you then mean a) it is ok with me that the packaging be infected with CDBS to improve backportability? Or did you instead mean that b) it is ok that the packaging is infected with short-form dh even though limiting backportability to stable+backports, oldstable+backports and similar. Packaging can support *both* multiarch *and* backportability to pure oldstable. I do recognize, however, that the use of CDBS is considered controversial by some, hence my asking instead of just doing it. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers I meant that's ok, you don't have to convert libdvdcss to cdbs. I want to keep libdvdcss build dependencies as minimal as possible, hence why dh-autoreconf was removed. The reason to keep them minimal is because the installer script builds the package on the user's system. Thus the installer would only need debhelper (= 8.1.3~), wget to get a snapshot of the git repository, apt for apt-get, and build-essential in order to build libdvdcss. -- ~ Andres ___ 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#664535: override: intel-vaapi-driver binary packages
Package: ftp.debian.org Severity: normal The override file needs to be updated for the following packages. i965-va-driver_1.0.16-1_all.deb: package says section is oldlibs, override says libs. i965-va-driver_1.0.16-1_all.deb: package says priority is extra, override says optional. This is now a transitional package. It should be oldlibs/extra. libva-intel-vaapi-driver_1.0.16-1_amd64.deb: package says priority is optional, override says extra. This is the new name for the libva VAAPI Intel driver package. It should be priority optional. ___ 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#664536: override: vo-aacenc0 binary packages
Package: ftp.debian.org Severity: normal The override file needs to be updated for the following packages. libvo-aacenc-dev_0.1.2-1_amd64.deb: package says priority is optional, override says extra. libvo-aacenc0_0.1.2-1_amd64.deb: package says priority is optional, override says extra. These packages should be Priority:optional. These packages can reasonably be used by anyone and don't require any specific setup or knowledge to use them or develop with them. ___ 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#664537: override: vo-amrwbenc binary packages
Package: ftp.debian.org Severity: normal The override file needs to be updated for the following packages. libvo-amrwbenc-dev_0.1.2-1_amd64.deb: package says priority is optional, override says extra. libvo-amrwbenc0_0.1.2-1_amd64.deb: package says priority is optional, override says extra. These packages should be Priority:optional. There is nothing particularly special about them. They don't require a specific system setup or special knowledge in order to use them or develop with them. ___ 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#664541: override: vainfo:utils/optional
Package: ftp.debian.org Severity: normal The override file needs to be updated for vainfo. vainfo_1.0.15-4_amd64.deb: package says section is utils, override says libs. vainfo is a utility program, not a library. ___ 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#658084: libav-extra: Really necessary?
Here is what I propose in order to provide the lib*extra* packages from the libav source package. [1] It essentially has libav building the extra packages, thus no longer having to rely on a seperate source package. This change ensures the regular and the extra packages are built for all 'flavors' to be built depending on the architecture. As I said before, as far as building the GPLv3 enabled libraries, there is no reason to do that with a seperate source package. Building them separately would not change the fact that the packages are ultimately distributed through Debian main. The source package will remain LGPLv2.1+. The binaries will be GPLv2+ for the regular packages, and GPLv3+ for the extra packages. Though the build time is increased for libav, ultimately, this change would be better as the buildd network would not have to cope with building from two source packages (i.e. setting up and tearing down for libav and libav-extra for each architecture). Also, in my opinion, it is easier and less error prone to maintain a single libav package rather than two of them. 1. http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=3037cab27717de75a73c77a553ab6dfad04a57da;hp=d78d2e6d0d0f43a6203ee6b78a8c0fefcab7838a -- ~ Andres ___ 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: Debian Multimedia (Unofficial) Promotion
On Sat, Mar 17, 2012 at 1:13 AM, Chris S. cs.swen...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As a new Debian user, I believe I read the following document about multimedia codes: http://wiki.debian.org/MultimediaCodecs However, as noted on the following two pages, Debian does not appear to approve of www.debian-multimedia.org: http://wiki.debian.org/DebianMultimedia/FAQ#Common_issues http://forum.videolan.org/viewtopic.php?t=70719f=13 So why would the first page about codecs instruct users to add the www.debian-multimedia.org repository? Shouldn't this be avoided? Shouldn't Debian communicate the contrary on all pages? I just finished downgrading all of the packages that I had linked to debian-multimedia.org, and it was a painful and slow process. Not something I would wish on anyone. It started because I was innocently trying to install VLC and some other video software, and I ran into package conflicts with GNOME and several other packages. So could we update the first link and remove the reference debian-multimedia.org? That would save newbie users like me from the pain of having to figure out why an innocent package in Stable conflicts with the entire GUI of the OS. Thank you for considering my input. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9kHX0ACgkQIZkx3dzEh22z5gCggbYg9XKnzGfmz1BydAbd/7pb aWUAoIDpXrvkvvm8a97odkUcjseHTXWg =MMvb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f641d7f.9040...@gmail.com Here's my first try at writing better documentation about installing extra multimedia codecs. Takes away the need for installing the deb line to apt. http://wiki.debian.org/MultimediaCodecs -- ~ Andres ___ 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: [SCM] libdvdcss/master: Update changelog.
On Sat, Mar 17, 2012 at 2:37 PM, ceros-gu...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit 15c3fdd600ad05440cfc3b9016897c523de68c0d Author: Andres Mejia amejia...@gmail.com Date: Sat Mar 17 14:36:37 2012 -0400 Update changelog. diff --git a/debian/changelog b/debian/changelog index 2fbd94f..b93d409 100644 --- a/debian/changelog +++ b/debian/changelog @@ -5,8 +5,10 @@ libdvdcss (1.2.12-2) UNRELEASED; urgency=low * Add myself to Uploaders field. * Bump to Standards-Version 3.9.3. * Make dev package multiarch installable installable. + * Ignore package-needs-versioned-debhelper-build-depends 9 lintian warning. + * Support parallel builds. - -- Andres Mejia ame...@debian.org Sat, 17 Mar 2012 14:29:56 -0400 + -- Andres Mejia ame...@debian.org Sat, 17 Mar 2012 14:36:21 -0400 libdvdcss (1.2.12-1) unstable; urgency=low -- libdvdcss packaging ___ pkg-multimedia-commits mailing list pkg-multimedia-comm...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-commits About these latest changes, I removed the build dependency on dh-autoreconf because a) it wasn't necessary, and b) because if we are to provide some install-css.sh script, it would be better if libdvdcss had as few build dependencies as possible. With this it only has two, debhelper (= 8.1.3~) and build-essential of course. That pretty much means libdvdcss can be compiled on Debian down to old-stable (if backports is used) and Ubuntu oneiric. For supporting Ubuntu suites before oneiric, we could use a seperate branch and modify the install-css.sh script accordingly. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
libdvdcss-installer - Package to install libdvdcss
On Sat, Mar 17, 2012 at 7:32 PM, ceros-gu...@users.alioth.debian.org wrote: The branch, master has been created at c4c77bca931e1dd7e0cce072985e694fcd5bb2e4 (commit) - Shortlog commit c4c77bca931e1dd7e0cce072985e694fcd5bb2e4 Author: Andres Mejia amejia...@gmail.com Date: Sat Mar 17 19:29:40 2012 -0400 Create new package for libdvdcss-installer. --- -- libdvdcss-installer packaging ___ pkg-multimedia-commits mailing list pkg-multimedia-comm...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-commits Ok, here was my idea of an installer for libdvdcss. This is it's very own package that can be installed via apt (i.e. apt-get install libdvdcss-installer). Through maintainer scripts, it can install, remove, and purge libdvdcss whenever the installer is installed, removed, and purged. I got this idea from a package I use to maintain long ago (nvidia-cg-toolkit) which works in similar fashion. My idea was to upload this to Debian contrib. If it failed to get accepted still, the script itself can be installed and used along with libdvdread instead. Maintainer scripts could be setup for libdvdread to automatically install/remove/purge libdvdcss, though the issue here is that libdvdread is in main. libdvdread must not depend on libdvdcss being available at all. libdvdcss-installer can be found at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libdvdcss-installer.git Any comments/concerns? -- ~ Andres ___ 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: [SCM] faad2/master: Set release as UNRELEASED. Current release hasn't been released yet.
On Fri, Mar 16, 2012 at 5:15 PM, ceros-gu...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit 0479ff2df5488335ee5d35de014a616410ec0add Author: Andres Mejia amejia...@gmail.com Date: Fri Mar 16 17:14:20 2012 -0400 Set release as UNRELEASED. Current release hasn't been released yet. diff --git a/debian/changelog b/debian/changelog index ca576b8..1d4f65f 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,4 +1,4 @@ -faad2 (2.7-8) unstable; urgency=low +faad2 (2.7-8) UNRELEASED; urgency=low * debian/patches/path_max.patch: + Dynamically allocate file name buffers, -- faad2 packaging ___ pkg-multimedia-commits mailing list pkg-multimedia-comm...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-commits Should this have been uploaded? I don't see a 2.7-8 release in either Debian or Ubuntu. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Fwd: Re: Unofficial repositories on 'debian' domains
This thread is from debian-devel. Would anyone here who had a lot of
experience working (or dealing) with Marillat like to respond?
~ Andres
-- Forwarded message --
From: Stefano Zacchiroli lea...@debian.org
Date: Mar 5, 2012 2:41 AM
Subject: Re: Unofficial repositories on apos;debianapos; domains
To: debian-de...@lists.debian.org
On Sun, Mar 04, 2012 at 10:59:39PM +, Ben Hutchings wrote:
Looking at the front page of http://www.debian-multimedia.org/ today,
I don't see a clear statement that it is unofficial.
Agreed.
I also find disturbing that the website seeks for donations without
making clear that donated money do not go to the Debian Project. That is
not necessarily done out of malice, of course, but it seems to live in
the same uncertainty about the unofficiality of the website that you
mention.
But for new users and potential users, this distinction probably isn't
obvious. There is a reason that Debian has pursued trademark
enforcement actions against various debian.xy domains.
Agreed, and I've been thinking about debian-multimedia.org since quite a
while. According to our trademark policy (present and draft), the
website is in violation of Debian trademark. As the website is
maintained by a Debian Developer, I'm sure we don't need that specific
aspect to come into some sort of amicable solution.
But before getting there, the question is whether the existence of the
website (and its popularity) poses problem to Debian reputation and/or
to the activity of official Debian multimedia packaging. I think this is
a question for the Debian Multimedia Maintainers (as in
pkg-multimedia-maintainers@lists.alioth.debian.org) to answer. If they
see a problem with debian-multimedia.org, we should get in touch with
the website maintainers and solve the issue.
And to avoid singling out debian-multimedia.org, I think this
confusion could just as well happen with repositories on
foo.debian.net domains.
I think the situations with debian.net is quite different. *.debian.net
is a namespace offered by Debian to developers that want to setup
services which are not (yet) integrated in the Debian infrastructure
and, as such, not yet blessed as official project services. I don't
think we need to have any stricter procedure that the current one for
people to setup *.debian.net entries.
What we need, though, is probably to make it more clear to our users
what is the difference among *.debian.net and *.debian.org services. It
is something that developers know by folklore, but that I seriously
doubt most of our users know. For me, the most appropriate way to do is
to put a splash page at www.debian.net explaining that. If DSA agrees
with that approach, I'm sure we can easily come up with a suitable
splash text.
While we are at it, I also think we should provide an index of
*.debian.net entries on that splash page.
http://wiki.debian.org/DebianNetDomains is just too prone to outdateness
and incompleteness. The index can be automatically generated from LDAP
and. IIRC a past chat with DSA, DSA is fine with that but is aware of
privacy concerns that some of the registrant of *.debian.net entries
might have. Personally, I don't think we should be worried about privacy
concerns there. The debian.net is a Debian project resource and we
should be ready to advertise all its entries, otherwise people should
not register them in the first place.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
___
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: lame_3.99.4+repack1-1_amd64.changes ACCEPTED into unstable
Ah yes sorry. Alioth was down when I uploaded and I forgot to push my changes afterwards. I can't push until later tonight. ~ Andres On Feb 13, 2012 8:56 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 31.01.2012 08:55, schrieb Fabian Greffrath: Thanks, Andres. Could you please push your Git tree to Alioth? Please push your changes, it's already diverging! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
