[PATCH 0/3] Proposed changes to LAME
Hi there. I am taking a look at packaging HandBrake for Debian and, while doing it, I noticed that we (Debian) had some patches against lame that were not applied in our (lame, upstream) tree. Some of the patches I saw in Debian's packaging effort that seem to be worth applying are included in this series. I did some facelifting here and there, to include more details in the changelog (for future reference---and tried to dig up some historical facts for justification of the patches). I hope that I have not broken anything in other environments (e.g., in Windows land or operating systems other than Debian/Ubuntu systems), but since I am not 100% confident with the changes, I am asking here for some peer-review. If I don't receive further feedback in 1 week, I will just commit the changes to the main branch of lame's CVS repo, but, of course, I would prefer to receive at least one ACK or NACK before doing so. Regards, Rogério Brito. Rogério Brito (3): configure.in: Rewrap for (human) legibility. acinclude.m4: Include GTK-1 autoconf directives in build system. libmp3lame: Fix possible race condition causing build failures. acinclude.m4| 193 +++ configure.in| 25 +- libmp3lame/i386/Makefile.am |8 +- 3 files changed, 221 insertions(+), 5 deletions(-) -- 1.7.10 From b160836f7a1d16a56d1add054b7a0e5d6a20a825 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rog=C3=A9rio=20Brito?= rbr...@ime.usp.br Date: Fri, 1 Jun 2012 02:21:58 -0300 Subject: [PATCH 1/3] configure.in: Rewrap for (human) legibility. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit To: lame-...@lists.sf.net Cc: pkg-multimedia-maintainers@lists.alioth.debian.org This also helps by being diff-friendly if we change only one of the parts of a long line. Signed-off-by: Rogério Brito rbr...@ime.usp.br --- configure.in | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/configure.in b/configure.in index edf39b8..46da876 100644 --- a/configure.in +++ b/configure.in @@ -1152,6 +1152,29 @@ AC_SUBST(CPUCCODE) AC_SUBST(CONFIG_DEFS) -AC_CONFIG_FILES([Makefile libmp3lame/Makefile libmp3lame/i386/Makefile libmp3lame/vector/Makefile frontend/Makefile mpglib/Makefile doc/Makefile doc/html/Makefile doc/man/Makefile include/Makefile Dll/Makefile misc/Makefile debian/Makefile dshow/Makefile ACM/Makefile ACM/ADbg/Makefile ACM/ddk/Makefile ACM/tinyxml/Makefile lame.spec mac/Makefile macosx/Makefile macosx/English.lproj/Makefile macosx/LAME.xcodeproj/Makefile vc_solution/Makefile]) +AC_CONFIG_FILES([Makefile \ +libmp3lame/Makefile \ +libmp3lame/i386/Makefile \ +libmp3lame/vector/Makefile \ +frontend/Makefile \ +mpglib/Makefile \ +doc/Makefile \ +doc/html/Makefile \ +doc/man/Makefile \ +include/Makefile \ +Dll/Makefile \ +misc/Makefile \ +debian/Makefile \ +dshow/Makefile \ +ACM/Makefile \ +ACM/ADbg/Makefile \ +ACM/ddk/Makefile \ +ACM/tinyxml/Makefile \ +lame.spec \ +mac/Makefile \ +macosx/Makefile \ +macosx/English.lproj/Makefile \ +macosx/LAME.xcodeproj/Makefile \ +vc_solution/Makefile]) AC_OUTPUT -- 1.7.10 From 27edb7f9472b5f727da9896d51235aeb71fc876d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rog=C3=A9rio=20Brito?= rbr...@ime.usp.br Date: Fri, 1 Jun 2012 02:43:00 -0300 Subject: [PATCH 2/3] acinclude.m4: Include GTK-1 autoconf directives in build system. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit To: lame-...@lists.sf.net Cc: pkg-multimedia-maintainers@lists.alioth.debian.org Resurrect knowledge of how to deal with GTK1. This was transplanted back from aclocal.m4 with a patch provided by Andres Mejia ame...@debian.org, from Debian's packaging of lame, even though the original code is attributed to Owen Taylor and dated 97-11-3. Anyway, with this part not lost again, we can easily regenerate autotools' files with a simple `autoconf -vfi` invocation. Signed-off-by: Rogério Brito rbr...@ime.usp.br --- acinclude.m4 | 193 ++ 1 file changed, 193 insertions(+) diff --git a/acinclude.m4 b/acinclude.m4 index 0b8f869..eef0c3d 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -85,4 +85,197 @@ int main(void) [AC_MSG_WARN(can't check for IEEE854 compliant 80 bit floats)] )])]) # alex_IEEE854_FLOAT80 +# Configure paths for GTK+ +# Owen Taylor 97-11-3 +dnl AM_PATH_GTK([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND [, MODULES) +dnl Test for GTK, and define GTK_CFLAGS and GTK_LIBS +dnl
[PATCH 2/3] acinclude.m4: Include GTK-1 autoconf directives in build system.
Resurrect knowledge of how to deal with GTK1. This was transplanted back
from aclocal.m4 with a patch provided by Andres Mejia ame...@debian.org,
from Debian's packaging of lame, even though the original code is attributed
to Owen Taylor and dated 97-11-3.
Anyway, with this part not lost again, we can easily regenerate autotools'
files with a simple `autoconf -vfi` invocation.
Signed-off-by: Rogério Brito rbr...@ime.usp.br
---
acinclude.m4 | 193 ++
1 file changed, 193 insertions(+)
diff --git a/acinclude.m4 b/acinclude.m4
index 0b8f869..eef0c3d 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -85,4 +85,197 @@ int main(void)
[AC_MSG_WARN(can't check for IEEE854 compliant 80 bit floats)]
)])]) # alex_IEEE854_FLOAT80
+# Configure paths for GTK+
+# Owen Taylor 97-11-3
+dnl AM_PATH_GTK([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND [,
MODULES)
+dnl Test for GTK, and define GTK_CFLAGS and GTK_LIBS
+dnl
+AC_DEFUN([AM_PATH_GTK],
+[dnl
+dnl Get the cflags and libraries from the gtk-config script
+dnl
+AC_ARG_WITH(gtk-prefix,[ --with-gtk-prefix=PFX Prefix where GTK is
installed (optional)],
+gtk_config_prefix=$withval, gtk_config_prefix=)
+AC_ARG_WITH(gtk-exec-prefix,[ --with-gtk-exec-prefix=PFX Exec prefix where
GTK is installed (optional)],
+gtk_config_exec_prefix=$withval, gtk_config_exec_prefix=)
+AC_ARG_ENABLE(gtktest, [ --disable-gtktest Do not try to compile and
run a test GTK program],
+, enable_gtktest=yes)
+
+ for module in . $4
+ do
+ case $module in
+ gthread)
+ gtk_config_args=$gtk_config_args gthread
+ ;;
+ esac
+ done
+
+ if test x$gtk_config_exec_prefix != x ; then
+ gtk_config_args=$gtk_config_args --exec-prefix=$gtk_config_exec_prefix
+ if test x${GTK_CONFIG+set} != xset ; then
+GTK_CONFIG=$gtk_config_exec_prefix/bin/gtk-config
+ fi
+ fi
+ if test x$gtk_config_prefix != x ; then
+ gtk_config_args=$gtk_config_args --prefix=$gtk_config_prefix
+ if test x${GTK_CONFIG+set} != xset ; then
+GTK_CONFIG=$gtk_config_prefix/bin/gtk-config
+ fi
+ fi
+
+ AC_PATH_PROG(GTK_CONFIG, gtk-config, no)
+ min_gtk_version=ifelse([$1], ,0.99.7,$1)
+ AC_MSG_CHECKING(for GTK - version = $min_gtk_version)
+ no_gtk=
+ if test $GTK_CONFIG = no ; then
+no_gtk=yes
+ else
+GTK_CFLAGS=`$GTK_CONFIG $gtk_config_args --cflags`
+GTK_LIBS=`$GTK_CONFIG $gtk_config_args --libs`
+gtk_config_major_version=`$GTK_CONFIG $gtk_config_args --version | \
+ sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\1/'`
+gtk_config_minor_version=`$GTK_CONFIG $gtk_config_args --version | \
+ sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\2/'`
+gtk_config_micro_version=`$GTK_CONFIG $gtk_config_args --version | \
+ sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\3/'`
+if test x$enable_gtktest = xyes ; then
+ ac_save_CFLAGS=$CFLAGS
+ ac_save_LIBS=$LIBS
+ CFLAGS=$CFLAGS $GTK_CFLAGS
+ LIBS=$GTK_LIBS $LIBS
+dnl
+dnl Now check if the installed GTK is sufficiently new. (Also sanity
+dnl checks the results of gtk-config to some extent
+dnl
+ rm -f conf.gtktest
+ AC_TRY_RUN([
+#include gtk/gtk.h
+#include stdio.h
+#include stdlib.h
+
+int
+main ()
+{
+ int major, minor, micro;
+ char *tmp_version;
+
+ system (touch conf.gtktest);
+
+ /* HP/UX 9 (%@#!) writes to sscanf strings */
+ tmp_version = g_strdup($min_gtk_version);
+ if (sscanf(tmp_version, %d.%d.%d, major, minor, micro) != 3) {
+ printf(%s, bad version string\n, $min_gtk_version);
+ exit(1);
+ }
+
+ if ((gtk_major_version != $gtk_config_major_version) ||
+ (gtk_minor_version != $gtk_config_minor_version) ||
+ (gtk_micro_version != $gtk_config_micro_version))
+{
+ printf(\n*** 'gtk-config --version' returned %d.%d.%d, but GTK+
(%d.%d.%d)\n,
+ $gtk_config_major_version, $gtk_config_minor_version,
$gtk_config_micro_version,
+ gtk_major_version, gtk_minor_version, gtk_micro_version);
+ printf (*** was found! If gtk-config was correct, then it is best\n);
+ printf (*** to remove the old version of GTK+. You may also be able to
fix the error\n);
+ printf(*** by modifying your LD_LIBRARY_PATH enviroment variable, or by
editing\n);
+ printf(*** /etc/ld.so.conf. Make sure you have run ldconfig if that
is\n);
+ printf(*** required on your system.\n);
+ printf(*** If gtk-config was wrong, set the environment variable
GTK_CONFIG\n);
+ printf(*** to point to the correct copy of gtk-config, and remove the
file config.cache\n);
+ printf(*** before re-running configure\n);
+}
+#if defined (GTK_MAJOR_VERSION) defined (GTK_MINOR_VERSION) defined
(GTK_MICRO_VERSION)
+ else if ((gtk_major_version != GTK_MAJOR_VERSION) ||
+ (gtk_minor_version != GTK_MINOR_VERSION) ||
+ (gtk_micro_version !=
[PATCH 3/3] libmp3lame: Fix possible race condition causing build failures.
This was discovered in automated builds by the Debian project and the patch provided is by Andres Mejia ame...@debian.org. Please, note that only part of the patch (the one touching Makefile.am) was applied, since the changes in Makefile.in should be picked up when regenerating files with autotools. Signed-off-by: Rogério Brito rbr...@ime.usp.br --- libmp3lame/i386/Makefile.am |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libmp3lame/i386/Makefile.am b/libmp3lame/i386/Makefile.am index a375225..032c2b2 100644 --- a/libmp3lame/i386/Makefile.am +++ b/libmp3lame/i386/Makefile.am @@ -15,6 +15,7 @@ nasm_sources = \ if HAVE_NASM noinst_LTLIBRARIES = liblameasmroutines.la liblameasmroutines_la_SOURCES = $(nasm_sources) +liblameasmroutines_la_DEPENDENCIES = $(nasm_sources:.nas.lo) am_liblameasmroutines_la_OBJECTS = \ choose_table$U.lo \ cpu_feat$U.lo \ @@ -53,11 +54,10 @@ NASMFLAGS=@NASM_FORMAT@ -i $(top_srcdir)/libmp3lame/@CPUTYPE@/ $(NASM) $(NASMFLAGS) $ -o $@ -l $@.lst .nas.lo: $ nasm.h - mkdir -p .libs $(ECHO) '# Generated by ltmain.sh - GNU libtool 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)' $@ - $(ECHO) pic_object='.libs/$*.o' $@ - $(ECHO) non_pic_object='.libs/$*.o' $@ - $(NASM) $(NASMFLAGS) $ -o .libs/$*.o -l $@.lst + $(ECHO) pic_object='$*.o' $@ + $(ECHO) non_pic_object='$*.o' $@ + $(NASM) $(NASMFLAGS) $ -o $*.o -l $@.lst COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \ $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -- 1.7.10 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
clothes dongli与您共享了照片
Hello, sir thank you for your time We are Dongli uniforms clothing manufactory, we mainly produce Uniforms, camouflage clothing and uniforms, currently we mainly export to Russian market and USA Market. If you are looking for this kinds clothing, please contact our factory by soonest. Our website: www.dongli-uniform.com email: sa...@dongli-uniform.com we welcome OEM clothing!! We are looking forward to getting your reply soonest thank you Robert Zeng Our website: www.dongli-uniform.com email: sa...@dongli-uniform.com attachment: 衣服dongli clothing.jpg___ 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: Request for upload: supercollider 3.5.2 new version
2012/5/31 Felipe Sateler fsate...@debian.org: On Thu, May 31, 2012 at 4:04 AM, Dan S danstowell+de...@gmail.com wrote: 2012/5/31 Felipe Sateler fsate...@debian.org: Dan, There are some breaks/replaces missing: Preparing to replace supercollider-common 1:3.4.5-1 (using supercollider-common_3.5.2-1_all.deb) ... Unpacking replacement supercollider-common ... dpkg: error processing supercollider-common_3.5.2-1_all.deb (--install): trying to overwrite '/usr/share/SuperCollider/Extensions/README', which is also in package supercollider-server 1:3.4.5-1 If files have been moved between binary packages, then Breaks + Replaces is necessary. Done, thanks. (Replaces feels odd since the -server package still exists, but it seems that's what the guide wants) Yes, because you are replacing an older version, so it is OK. However, I see another thing. I see that MathJax is included in the binary packages. Can't we use libjs-mathjax? I don't really know mathjax myself but it looks like, technically, it could be patched to use libjs-mathjax, as long as our custom config file HelpSource/MathJax/config/scmathjax.js was installed in the appropriate place. However, the rendered help is supposed to be self-contained in the sense that it can be uploaded to a website (we do this with http://doc.sccode.org ) so if the URLs were rewritten to use /usr/share/javascript/mathjax/... then this would break. (And the help is supposed to be re-rendered by users - when the user installs an extension the rendering process is re-run locally.) So this makes me think that we would prefer not to. Is that OK with you? Dan ___ 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: Request for upload: supercollider 3.5.2 new version
Hi Dan, On 12-06-01 at 08:56am, Dan S wrote: 2012/5/31 Felipe Sateler fsate...@debian.org: I see that MathJax is included in the binary packages. Can't we use libjs-mathjax? I don't really know mathjax myself but it looks like, technically, it could be patched to use libjs-mathjax, as long as our custom config file HelpSource/MathJax/config/scmathjax.js was installed in the appropriate place. However, the rendered help is supposed to be self-contained in the sense that it can be uploaded to a website (we do this with http://doc.sccode.org ) so if the URLs were rewritten to use /usr/share/javascript/mathjax/... then this would break. (And the help is supposed to be re-rendered by users - when the user installs an extension the rendering process is re-run locally.) So this makes me think that we would prefer not to. Is that OK with you? Probably a good idea to then raise that issue over at pkg-javascript-de...@lists.alioth.debian.org (since you most likely are not subscribed to that list, please remember to mention in the email that you want to be cc'ed on replies). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Request for upload: supercollider 3.5.2 new version
2012/6/1 Jonas Smedegaard d...@jones.dk: Hi Dan, On 12-06-01 at 08:56am, Dan S wrote: 2012/5/31 Felipe Sateler fsate...@debian.org: I see that MathJax is included in the binary packages. Can't we use libjs-mathjax? I don't really know mathjax myself but it looks like, technically, it could be patched to use libjs-mathjax, as long as our custom config file HelpSource/MathJax/config/scmathjax.js was installed in the appropriate place. However, the rendered help is supposed to be self-contained in the sense that it can be uploaded to a website (we do this with http://doc.sccode.org ) so if the URLs were rewritten to use /usr/share/javascript/mathjax/... then this would break. (And the help is supposed to be re-rendered by users - when the user installs an extension the rendering process is re-run locally.) So this makes me think that we would prefer not to. Is that OK with you? Hi Jonas - Probably a good idea to then raise that issue over at pkg-javascript-de...@lists.alioth.debian.org (since you most likely are not subscribed to that list, please remember to mention in the email that you want to be cc'ed on replies). I'm not sure there's an issue here that they can help with, unless I misunderstand? The issue is that the SC rendered helpfiles currently have a reference like this: script src='./MathJax/MathJax.js?config=TeX-AMS_HTML,scmathjax' type='text/javascript'/script and if we used the libjs-mathjax package, the rendered helpfiles would have a reference like this: script src='/usr/share/javascript/mathjax/MathJax.js?config=TeX-AMS_HTML,scmathjax' type='text/javascript'/script This is unportable for exported helpfiles and that's why I'd prefer not to do it. It's OK for other software which expects to render the math on-the-fly for the local user and not export it anywhere. (For example ipython-notebook-common depends on the lib - I guess it's doing local math rendering only...) Please let me know what you think. I'll also pass this on to the person who actually did the mathjax bit and see if they have a good way round. Thanks Dan ___ 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: Request for upload: supercollider 3.5.2 new version
On Jun 1, 2012 7:04 AM, Dan S danstowell+de...@gmail.com wrote: 2012/6/1 Jonas Smedegaard d...@jones.dk: Hi Dan, On 12-06-01 at 08:56am, Dan S wrote: 2012/5/31 Felipe Sateler fsate...@debian.org: I see that MathJax is included in the binary packages. Can't we use libjs-mathjax? I don't really know mathjax myself but it looks like, technically, it could be patched to use libjs-mathjax, as long as our custom config file HelpSource/MathJax/config/scmathjax.js was installed in the appropriate place. However, the rendered help is supposed to be self-contained in the sense that it can be uploaded to a website (we do this with http://doc.sccode.org ) so if the URLs were rewritten to use /usr/share/javascript/mathjax/... then this would break. (And the help is supposed to be re-rendered by users - when the user installs an extension the rendering process is re-run locally.) So this makes me think that we would prefer not to. Is that OK with you? Another option is to create a linkfarm pointing to the real mathjax sources. This would avoid the problem, wouldn't it? I think Raphael Hertzog wrote a tool precisely for this. I'm not on a computer now, though, so I can't search for it. Hi Jonas - Probably a good idea to then raise that issue over at pkg-javascript-de...@lists.alioth.debian.org (since you most likely are not subscribed to that list, please remember to mention in the email that you want to be cc'ed on replies). I'm not sure there's an issue here that they can help with, unless I misunderstand? The issue is that the SC rendered helpfiles currently have a reference like this: script src='./MathJax/MathJax.js?config=TeX-AMS_HTML,scmathjax' type='text/javascript'/script and if we used the libjs-mathjax package, the rendered helpfiles would have a reference like this: script src='/usr/share/javascript/mathjax/MathJax.js?config=TeX-AMS_HTML,scmathjax' type='text/javascript'/script This is unportable for exported helpfiles and that's why I'd prefer not to do it. It's OK for other software which expects to render the math on-the-fly for the local user and not export it anywhere. (For example ipython-notebook-common depends on the lib - I guess it's doing local math rendering only...) Please let me know what you think. I'll also pass this on to the person who actually did the mathjax bit and see if they have a good way round. I think the idea was that maybe in that team somebody already had the same problem and they could have a different solution. ___ 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: Request for upload: supercollider 3.5.2 new version
On Fri, Jun 1, 2012 at 9:01 AM, Felipe Sateler fsate...@gmail.com wrote: On Jun 1, 2012 7:04 AM, Dan S danstowell+de...@gmail.com wrote: 2012/6/1 Jonas Smedegaard d...@jones.dk: Hi Dan, On 12-06-01 at 08:56am, Dan S wrote: 2012/5/31 Felipe Sateler fsate...@debian.org: I see that MathJax is included in the binary packages. Can't we use libjs-mathjax? I don't really know mathjax myself but it looks like, technically, it could be patched to use libjs-mathjax, as long as our custom config file HelpSource/MathJax/config/scmathjax.js was installed in the appropriate place. However, the rendered help is supposed to be self-contained in the sense that it can be uploaded to a website (we do this with http://doc.sccode.org ) so if the URLs were rewritten to use /usr/share/javascript/mathjax/... then this would break. (And the help is supposed to be re-rendered by users - when the user installs an extension the rendering process is re-run locally.) So this makes me think that we would prefer not to. Is that OK with you? Another option is to create a linkfarm pointing to the real mathjax sources. This would avoid the problem, wouldn't it? I think Raphael Hertzog wrote a tool precisely for this. I'm not on a computer now, though, so I can't search for it. Found it http://packages.debian.org/unstable/dh-linktree -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#672824: Bug#673263: Bug#590905: libmysqld-dev: Missing dependency or wrong flags in mysql_config
Rene Engelhard, le Wed 30 May 2012 09:41:28 +0200, a écrit : Samuel, you probably should check all those and clean this up... They all work fine now indeed, closing the remainders. Samuel ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
libquicktime 2:1.2.4-3 MIGRATED to testing
FYI: The status of the libquicktime source package in Debian's testing distribution has changed. Previous version: 2:1.2.4-2 Current version: 2:1.2.4-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
projectm 2.1.0+dfsg-1 MIGRATED to testing
FYI: The status of the projectm source package in Debian's testing distribution has changed. Previous version: 2.0.1+dfsg-12 Current version: 2.1.0+dfsg-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
pugl 0~svn32+dfsg0-1 MIGRATED to testing
FYI: The status of the pugl source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 0~svn32+dfsg0-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
guayadeque 0.3.5~ds0-4 MIGRATED to testing
FYI: The status of the guayadeque source package in Debian's testing distribution has changed. Previous version: 0.3.5~ds0-3 Current version: 0.3.5~ds0-4 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
volti 0.2.3-3 MIGRATED to testing
FYI: The status of the volti source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 0.2.3-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Checking if handbrake compiles under kFreeBSD?
Hi, Pino and others.
On Thu, May 24, 2012 at 7:46 AM, Pino Toscano p...@debian.org wrote:
Alle domenica 20 maggio 2012, Rogério Brito ha scritto:
I'm adding the HURD people here, so that they can test the package
and see if something should be done or not.
For the HURD people, this is a reply to [my first e-mail][*] about
getting the HandBrake ripper/transcoder working on kFreeBSD and
patches that need to be added for building:
[*]: http://lists.debian.org/debian-bsd/2012/05/msg00198.html
Thanks for aking, although currently I cannot test it due to libfaac and
libmp4v2 not being yet available.
There pre-ready packages of these packages in the git trees of the
pkg-multimedia team, but we are trying to make them both unused (by
licensing reasons) by substituting with freeer alternatives. This is a
work in progress.
Although, I can provide some hints to help.
Thanks. I have committed your comments in [our git tree][0].
[0]: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/handbrake.git
When building, I noticed it wget's from download.handbrake.fr a svn
snapshot of libdvdread; note this is not acceptable at all in Debian for
two reasons:
- a package build must use only things available within the sources
themselves (and of course stuff installed as build dependency too)
- we have libdvdread in Debian already (which has been fixed for Hurd,
unlike that copy that fails)
Yes, I know that. HandBrake's build system is kind of crazy in that it
pulls its dependencies from their site and *patches* those packages in
customized ways.
We are working on that so that it can be readily compiled with the
versions of packages that we have in Debian.
Furthermore, please disable (or make it optional) the use of ccache;
while it may be useful during test builds, it is close to useless when
doing builds in buildds.
If I recall correctly, the use of ccache violates the policy, but I am
keeping it there because I'm compiling and recompiling things over and
over here. The version of the package that will be uploaded to the
repository (when it happens) will be cleaned up, without those
extraneous things.
Last, I attached a preliminary version of patch for Hurd support; as
said above I couldn't go far in the build, although what I have so far
would seem safe enough.
Thanks for all the comments. They have been very constructive.
--
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
Re: Checking if handbrake compiles under kFreeBSD?
Hi, Fabian.
On Fri, May 25, 2012 at 4:32 PM, Fabian Greffrath fab...@greffrath.com wrote:
When building, I noticed it wget's from download.handbrake.fr a svn
snapshot of libdvdread; note this is not acceptable at all in Debian for
two reasons:
Good news! The next release of libdvdnav will contain the patchset that
handbrake applies, please see the threat starting here:
http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/2012-May/001715.html
That's really great. Thanks for the pointer.
I just sent a wishlist bug to libdvdnav so that we can have those
changes and be one package closer to having handbrake in the repos.
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
