Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
Hi all, Am 07.06.2010 11:50, schrieb Sebastian Dröge: Or at least a -fPIC static library? :) given that upstream already has a rtmpsrc gstreamer-plugin in the bad set waiting (thanks slomo), I'd like to take action on this issue. My question is, how to do it best? 1) Build the library only once but with -fPIC. Does this have an effect on other non-library binaries linking against it? (If not, why don't we build all static libraries in Debian with -fPIC?) 2) We build the library twice in debian/rules, once with and once without -fPIC. a) We rename the -fPIC variant to librtmp_pic.a and install it into librtmp-dev in addition the non-PIC library. (This would probably also require some patching against the pkg-config file.) b) Both variants will be called librtmp.a but installed into different packages librtmp-dev and libtrmp_pic-dev which conflict against each other. (This would require a separate pkg-config file for each variant.) 3) We build the library twice, but patch upstream's Makefile to do so. Any more ideas? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#585380: [audacity] hangs suddenly, can't find a pattern. Here is one bug trace.
On Thu, Jun 10, 2010 at 01:27:26AM +0200, Arnfinn Ringvold wrote: Package: audacity Version: 1.3.5-2+lenny1 Audacity appears to be differently broken in every new version. We have 1.3.12-3 now, so I don't see any use in even looking at this bug. Though I'm not the maintainer and therefore cannot speak how the official approach to your report will be, the best advice I could give at the moment is to try a newer version, preferably the one from sid. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
Hi Howard, in our multimedia packaging team, there is some interest by various people to use librtmp inside shared libraries like libavformat.so or gstreamer modules. This requires compiling the library as position independent code (PIC). Would you consider a patch for building a shared library librtmp.so for the next release? This way we could have both a PIC and a non-PIC version, and avoid code duplications across application packages. The downside of this would be of course the (well known) overhead of shared library maintenance. Please share your thoughts on this topic with us :-) regards, Reinhard On Thu, Jun 10, 2010 at 09:46:07 (CEST), Fabian Greffrath wrote: Hi all, Am 07.06.2010 11:50, schrieb Sebastian Dröge: Or at least a -fPIC static library? :) given that upstream already has a rtmpsrc gstreamer-plugin in the bad set waiting (thanks slomo), I'd like to take action on this issue. My question is, how to do it best? 1) Build the library only once but with -fPIC. Does this have an effect on other non-library binaries linking against it? (If not, why don't we build all static libraries in Debian with -fPIC?) 2) We build the library twice in debian/rules, once with and once without -fPIC. a) We rename the -fPIC variant to librtmp_pic.a and install it into librtmp-dev in addition the non-PIC library. (This would probably also require some patching against the pkg-config file.) b) Both variants will be called librtmp.a but installed into different packages librtmp-dev and libtrmp_pic-dev which conflict against each other. (This would require a separate pkg-config file for each variant.) 3) We build the library twice, but patch upstream's Makefile to do so. Any more ideas? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
On Wed, Jun 09, 2010 at 09:18:14PM -0400, Alexandre Quessy wrote: Still working on this... It's not easy, but it's likely I will work with more free projects involving multimedia, Python and the autotools for a little while again. :) Happy to hear that these challenges haven't turned you off. 2010/6/9 Jonas Smedegaard d...@jones.dk: It should be DEB_PYTHON_MODULE_PACKAGES (not DEB_PYTHON_PACKAGES) Thanks! It seems to work now. It's nice that it takes care of deleting the .pyo files. The .pyc files are byte-compiled for Python 2.5, but it seems to work with 2.6 as well. Good. Not sure I read you correctly above: Do the snippet only cleanup half of the Python compiled files? If you seem to reveal weaknesses in the CDBS snippets then do tell - so I can improve them for the benefit of all (except those poor souls not seeing the light of CDBS ;-) ). Try extend the PYTHONPATH in the check target. Best to use make variable expansion using some of the variables calculated in /usr/share/cdbs/1/class/python-vars.mk. If that fails to work then disable tests for now. I find it better to properly use python-autotools.mk than running the tests. But beware that since you know that the packaging should fail to build on certain architectures, then if for some reason some of those known failures only are discovered in the regression tests (as opposed to missing build-dependencies which is the more likely to happen) then the trick of not declaring specific supported archs but just rely on never succesfully built before on that arch will fail if postponing regression tests for later. Well, since the unit tests mostly test the Python code, I disabled it for now. I added the perl one-liner in the binary-fixup/scenic target. It doesn't replace the #! line in the scripts, though. Maybe I should add more rules or set something somewhere else? Well, my idea was not to use it verbatim (although if relevant you can - and should - off course do that as well) but instead adapt it for use with the regression tests: I did not inspect the code, but imagined that in addition to adding a PYTHONPATH you might need to adjust hashbangs in tests as well. If you want an example of custom PYTHONPATH export, have a look at radicale (one of my latest packagings). Otherwise, I think this packaging stuff is going well. The upstream team will be ready for the 0.6.0 release for Friday, I think. Sounds good. But we need not delay releasing this packaging until then: approval from ftpmasters may take time, so better get in in as soon as we feel the packaging is acceptable. Even if you know that this upstream code is flawed, we can still release but (if needed) immediately file a severe bugreport against it to block it from entering testing. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
On Thu, Jun 10, 2010 at 10:37:23 (CEST), Howard Chu wrote: Reinhard Tartler wrote: Hi Howard, in our multimedia packaging team, there is some interest by various people to use librtmp inside shared libraries like libavformat.so or gstreamer modules. This requires compiling the library as position independent code (PIC). Would you consider a patch for building a shared library librtmp.so for the next release? This way we could have both a PIC and a non-PIC version, and avoid code duplications across application packages. The downside of this would be of course the (well known) overhead of shared library maintenance. If you submit a patch I'll take a look. I'm not ready to go there yet myself, there are other loose ends that still need to be tied up first. Thanks for this input. I guess we should stick with a static library for now until we have some packages actually using librtmp. Please share your thoughts on this topic with us :-) regards, Reinhard On Thu, Jun 10, 2010 at 09:46:07 (CEST), Fabian Greffrath wrote: Hi all, Am 07.06.2010 11:50, schrieb Sebastian Dröge: Or at least a -fPIC static library? :) Obviously this is what I recommend for now. given that upstream already has a rtmpsrc gstreamer-plugin in the bad set waiting (thanks slomo), I'd like to take action on this issue. My question is, how to do it best? 1) Build the library only once but with -fPIC. Does this have an effect on other non-library binaries linking against it? (If not, why don't we build all static libraries in Debian with -fPIC?) -fPIC code on most platforms is a little slower than non-PIC; that's the reason most systems don't build this way by default. Some notable exceptions I recall are AIX/POWER (all binaries are PIC) and M68K (PIC was actually more compact and faster in many cases). I think on modern systems the difference is negligible. 2) We build the library twice in debian/rules, once with and once without -fPIC. a) We rename the -fPIC variant to librtmp_pic.a and install it into librtmp-dev in addition the non-PIC library. (This would probably also require some patching against the pkg-config file.) b) Both variants will be called librtmp.a but installed into different packages librtmp-dev and libtrmp_pic-dev which conflict against each other. (This would require a separate pkg-config file for each variant.) Sounds like a lot of hassle for no real reason. I guess we should go then with a), or c): don't provide a non-PIC .a file at all. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
Am 10.06.2010 10:37, schrieb Howard Chu: If you submit a patch I'll take a look. I'm not ready to go there yet myself, there are other loose ends that still need to be tied up first. Here you go! From 34dd288920eaf70f4a6abcecf8a63c185b9912e6 Mon Sep 17 00:00:00 2001 From: Fabian Greffrath fab...@greffrath.com Date: Thu, 10 Jun 2010 11:22:54 +0200 Subject: [PATCH] Build a shared library. --- librtmp/Makefile | 36 +++- 1 files changed, 31 insertions(+), 5 deletions(-) diff --git a/librtmp/Makefile b/librtmp/Makefile index 88fd611..bc5b939 100644 --- a/librtmp/Makefile +++ b/librtmp/Makefile @@ -28,12 +28,17 @@ INCDIR=$(DESTDIR)$(incdir) LIBDIR=$(DESTDIR)$(libdir) MANDIR=$(DESTDIR)$(mandir) -all: librtmp.a +LIBRARY=librtmp.a +LIBRARY_SO=librtmp.so +LIBRARY_SO_VER=librtmp.so.0 + +all: $(LIBRARY) $(LIBRARY_SO) clean: - rm -f *.o *.a + rm -f *.a *.lo *.o *.so *.so.* -librtmp.a: rtmp.o log.o amf.o hashswf.o parseurl.o +# Static library +$(LIBRARY): rtmp.o log.o amf.o hashswf.o parseurl.o $(AR) rs $@ $? log.o: log.c log.h Makefile @@ -42,13 +47,34 @@ amf.o: amf.c amf.h bytes.h log.h Makefile hashswf.o: hashswf.c http.h rtmp.h rtmp_sys.h Makefile parseurl.o: parseurl.c rtmp.h rtmp_sys.h log.h Makefile +%.o: %.c + $(CC) $(CFLAGS) -o $@ -c $ + +# shared library +$(LIBRARY_SO_VER): rtmp.lo log.lo amf.lo hashswf.lo parseurl.lo + $(CC) -shared -Wl,-soname,$@ $(LDFLAGS) -o $@ $? + +$(LIBRARY_SO): $(LIBRARY_SO_VER) + ln -sf $? $@ + +log.lo: log.c log.h Makefile +rtmp.lo: rtmp.c rtmp.h rtmp_sys.h handshake.h dh.h log.h amf.h Makefile +amf.lo: amf.c amf.h bytes.h log.h Makefile +hashswf.lo: hashswf.c http.h rtmp.h rtmp_sys.h Makefile +parseurl.lo: parseurl.c rtmp.h rtmp_sys.h log.h Makefile + +%.lo: %.c + $(CC) $(CFLAGS) -fPIC -o $@ -c $ + librtmp.pc: librtmp.pc.in Makefile sed -e s;@prefix@;$(prefix); -e s;@VERSION@;$(VERSION); \ -e s;@CRYPTO_REQ@;$(CRYPTO_REQ); librtmp.pc.in $@ -install: librtmp.a librtmp.pc +install: $(LIBRARY) $(LIBRARY_SO) librtmp.pc -mkdir -p $(INCDIR) $(LIBDIR)/pkgconfig $(MANDIR)/man3 cp amf.h http.h log.h rtmp.h $(INCDIR) - cp librtmp.a $(LIBDIR) + cp $(LIBRARY) $(LIBDIR) + cp $(LIBRARY_SO) $(LIBDIR) + cp $(LIBRARY_SO_VER) $(LIBDIR) cp librtmp.pc $(LIBDIR)/pkgconfig cp librtmp.3 $(MANDIR)/man3 -- 1.7.1 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Comments regarding libebml_1.0.0-1_i386.changes
Hi Maintainer! I'm going to accept your package, but could you please clarify the license of your deian/* files in a succeding upload? I guess you intended to license is under the terms of the GPL (as you refer to the GPL at the bottom of it). Best regards, Alexander ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
libebml_1.0.0-1_i386.changes ACCEPTED
Accepted: libebml-dev_1.0.0-1_i386.deb to main/libe/libebml/libebml-dev_1.0.0-1_i386.deb libebml2_1.0.0-1_i386.deb to main/libe/libebml/libebml2_1.0.0-1_i386.deb libebml_1.0.0-1.debian.tar.gz to main/libe/libebml/libebml_1.0.0-1.debian.tar.gz libebml_1.0.0-1.dsc to main/libe/libebml/libebml_1.0.0-1.dsc libebml_1.0.0.orig.tar.bz2 to main/libe/libebml/libebml_1.0.0.orig.tar.bz2 Override entries for your package: libebml-dev_1.0.0-1_i386.deb - optional libdevel libebml2_1.0.0-1_i386.deb - optional libs libebml_1.0.0-1.dsc - source libs Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 582238 Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#582238: marked as done (libebml: New upstream release 0.8.0)
Your message dated Thu, 10 Jun 2010 11:32:24 + with message-id e1omfzk-0005cg...@ries.debian.org and subject line Bug#582238: fixed in libebml 1.0.0-1 has caused the Debian Bug report #582238, regarding libebml: New upstream release 0.8.0 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 582238: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582238 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: libebml0 Version: 0.7.7-3.1 Severity: normal File: libebml Hi, Please package this version. Christian -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.34 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libebml0 depends on: ii libc6 2.10.2-8 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.4-2 GCC support library ii libstdc++64.4.4-2The GNU Standard C++ Library v3 libebml0 recommends no packages. libebml0 suggests no packages. -- no debconf information ---End Message--- ---BeginMessage--- Source: libebml Source-Version: 1.0.0-1 We believe that the bug you reported is fixed in the latest version of libebml, which is due to be installed in the Debian FTP archive: libebml-dev_1.0.0-1_i386.deb to main/libe/libebml/libebml-dev_1.0.0-1_i386.deb libebml2_1.0.0-1_i386.deb to main/libe/libebml/libebml2_1.0.0-1_i386.deb libebml_1.0.0-1.debian.tar.gz to main/libe/libebml/libebml_1.0.0-1.debian.tar.gz libebml_1.0.0-1.dsc to main/libe/libebml/libebml_1.0.0-1.dsc libebml_1.0.0.orig.tar.bz2 to main/libe/libebml/libebml_1.0.0.orig.tar.bz2 A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 582...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Fabian Greffrath fabian+deb...@greffrath.com (supplier of updated libebml package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 08 Jun 2010 23:13:59 +0200 Source: libebml Binary: libebml2 libebml-dev Architecture: source i386 Version: 1.0.0-1 Distribution: experimental Urgency: low Maintainer: Debian multimedia packages maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Changed-By: Fabian Greffrath fabian+deb...@greffrath.com Description: libebml-dev - access library for the EBML format (development files) libebml2 - access library for the EBML format (shared library) Closes: 582238 Changes: libebml (1.0.0-1) experimental; urgency=low . [ Reinhard Tartler ] * remove generated files from branch * add .gitignore file * bump shlips * remove debian/patches/010_propagate_cflags.diff hack * remove debian/patches/020_invalid_cast.diff, applied upstream * remove debian/patches/030_g++-4.3.diff, merged upstream * don't create usr/include in libebml0 package . [ Fabian Greffrath ] * Add debian/watch. * Add debian/gbp.conf. * Imported Upstream version 1.0.0 (Closes: #582238). . [ Reinhard Tartler ] * prepare new upload * convert to Source Format 3.0 (quilt) * update Vcs- headers . [ Fabian Greffrath ] * Remove useless debian/*.dirs. * Bump library soname to libebml2. * Convert Debian packaging to dh 7. * Add myself to Uploaders. * Bump Standards-Version to 3.8.4. * Fix weak-library-dev-dependency. * Fix debhelper-but-no-misc-depends. * Wrap lines in debian/control. * Fix duplicate-short-description. * Fix old-fsf-address-in-copyright-file. Checksums-Sha1: 29f9fa49f8245a6cc13a6e89bec55080f659339c 1428 libebml_1.0.0-1.dsc 8b79752ddb6cadab0346b43785432c554dbf220d 60058 libebml_1.0.0.orig.tar.bz2 cbf53d075ee1adada10b0d200fa922eb5a21711b 3834 libebml_1.0.0-1.debian.tar.gz 2892115cdbfa19704425041bf71dd99a5844c53a 68630 libebml2_1.0.0-1_i386.deb 9cb08f6670c83e1f03452016f20d64595f94e9d5 99760 libebml-dev_1.0.0-1_i386.deb Checksums-Sha256: c095faf7b77ff490ef31f0fb05529a1437b7a6104984ed70c335494b18b9c31b 1428 libebml_1.0.0-1.dsc 72480dec736cd5df5bc9e8c3864a58d17715542c83ff1b2095dca46cc1b8b178 60058 libebml_1.0.0.orig.tar.bz2
Verbose build log
Hello, VLC 1.1.0 uses automake 1.11 and so the build can produce non-verbose logs like the kernel does for some years. CC foo.o CCLD foo.so ... We can revert to the old fully verbose behaviour if we like. Do you know if there is a Debian or pkg-multimedia policy/best-practice on this matter. Verbose log can help debug FTBFS but increase the size of the log by 2 or 3 order of magnitude Regards -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
xbmc - libcdio patch
Hi,
I tested official XBMC installation instructions as written on
http://wiki.xbmc.org/index.php?title=XBMCbuntu with latest ubuntu distro
and xbmc packets from ppa repository.
(http://ppa.launchpad.net/team-xbmc/ppa/ubuntu/dists/lucid)
It seems that xbmc 1:9.11-lucid2 has same problem like xbmc from
debian-multimedia repository had some time ago. Problem was corrected
with same patch which I'm sending to You.
Would you please consider to include this patch in current XBMC packet
(9.11-lucid2) which will fix bug/problem when xbmc tries to use CD/DVD unit.
According to the developers, that problem is solved in resent SVN
version, but until then... :)
Well to be short, whole problem is discussed in following thread:
http://trac.xbmc.org/ticket/8026
There is a patch on that same page, and I only adapted it to apply
cleanly to xbmc source.
Packets are tested on ubuntu lucid amd64 and they are working like
expected.
THX in advance.
Best regards,
Sasa Davidovic
diff --git a/xbmc/Application.cpp b/xbmc/Application.cpp
index 9097519..9b6418d 100644
--- a/xbmc/Application.cpp
+++ b/xbmc/Application.cpp
@@ -236,7 +236,11 @@
#endif
#ifdef HAS_DVD_DRIVE
+#ifdef _WIN32
#include lib/libcdio/logging.h
+#else
+#include cdio/logging.h
+#endif
#endif
#ifdef HAS_HAL
diff --git a/xbmc/FileSystem/Makefile b/xbmc/FileSystem/Makefile
index 782d57a..1e524ed 100644
--- a/xbmc/FileSystem/Makefile
+++ b/xbmc/FileSystem/Makefile
@@ -1,5 +1,4 @@
INCLUDES=-I. -I../ -I../cores -I../linux -I../../guilib -I../lib/UnrarXLib -I../utils -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-INCLUDES+=-I../lib/libcdio/libcdio/include
CXXFLAGS+=-D__STDC_FORMAT_MACROS \
diff --git a/xbmc/FileSystem/cdioSupport.cpp b/xbmc/FileSystem/cdioSupport.cpp
index 00e5fdd..21a0b67 100644
--- a/xbmc/FileSystem/cdioSupport.cpp
+++ b/xbmc/FileSystem/cdioSupport.cpp
@@ -26,7 +26,7 @@
#include cdioSupport.h
#include utils/SingleLock.h
#include utils/log.h
-#ifndef _LINUX
+#ifdef _WIN32
#include lib/libcdio/logging.h
#include lib/libcdio/util.h
#include lib/libcdio/mmc.h
diff --git a/xbmc/FileSystem/iso9660.cpp b/xbmc/FileSystem/iso9660.cpp
index 6e1633f..58fbc50 100644
--- a/xbmc/FileSystem/iso9660.cpp
+++ b/xbmc/FileSystem/iso9660.cpp
@@ -44,7 +44,7 @@ ISO9660
#include utils/CharsetConverter.h
#include DetectDVDType.h // for MODE2_DATA_SIZE etc.
-#ifdef _LINUX
+#ifndef _WIN32
#include cdio/bytesex.h
#else
#include lib/libcdio/bytesex.h // for from_723 from_733
diff --git a/xbmc/Makefile b/xbmc/Makefile
index abfbdcb..f55381a 100644
--- a/xbmc/Makefile
+++ b/xbmc/Makefile
@@ -8,8 +8,6 @@ INCLUDES+=-Ilib/libUPnP/Platinum/Source/Core \
-Ilib/libUPnP/Neptune/Source/System/Posix \
-Ilib/libUPnP/Neptune/Source/Core
-INCLUDES+=-Ilib/libcdio/libcdio/include
-
SRCS=Application.cpp \
CueDocument.cpp \
GUISettings.cpp \
diff --git a/xbmc/cdrip/CDDAReader.cpp b/xbmc/cdrip/CDDAReader.cpp
index c8b37b2..e3e9c0b 100644
--- a/xbmc/cdrip/CDDAReader.cpp
+++ b/xbmc/cdrip/CDDAReader.cpp
@@ -24,7 +24,11 @@
#ifdef HAS_CDDA_RIPPER
#include CDDAReader.h
+#ifdef _WIN32
#include lib/libcdio/cdio.h
+#else
+#include cdio/cdio.h
+#endif
#include utils/log.h
#define SECTOR_COUNT 52
diff --git a/xbmc/cores/paplayer/AC3CDDACodec.cpp b/xbmc/cores/paplayer/AC3CDDACodec.cpp
index 20cded7..f2a077a 100644
--- a/xbmc/cores/paplayer/AC3CDDACodec.cpp
+++ b/xbmc/cores/paplayer/AC3CDDACodec.cpp
@@ -22,7 +22,11 @@
#include system.h
#include AC3CDDACodec.h
#ifdef HAS_AC3_CDDA_CODEC
+#ifdef _WIN32
#include lib/libcdio/sector.h
+#else
+#include cdio/sector.h
+#endif
AC3CDDACodec::AC3CDDACodec() : AC3Codec()
{
diff --git a/xbmc/cores/paplayer/CDDAcodec.cpp b/xbmc/cores/paplayer/CDDAcodec.cpp
index ca8f1be..42460dc 100644
--- a/xbmc/cores/paplayer/CDDAcodec.cpp
+++ b/xbmc/cores/paplayer/CDDAcodec.cpp
@@ -20,7 +20,11 @@
*/
#include CDDAcodec.h
+#ifdef _WIN32
#include lib/libcdio/sector.h
+#else
+#include cdio/sector.h
+#endif
#define SECTOR_COUNT 55 // max. sectors that can be read at once
#define MAX_BUFFER_SIZE 2*SECTOR_COUNT*CDIO_CD_FRAMESIZE_RAW
diff --git a/xbmc/cores/paplayer/DTSCDDACodec.cpp b/xbmc/cores/paplayer/DTSCDDACodec.cpp
index e64cc2e..9bc46c6 100644
--- a/xbmc/cores/paplayer/DTSCDDACodec.cpp
+++ b/xbmc/cores/paplayer/DTSCDDACodec.cpp
@@ -22,7 +22,11 @@
#include system.h
#include DTSCDDACodec.h
#ifdef HAS_DTS_CODEC
+#ifdef _WIN32
#include lib/libcdio/sector.h
+#else
+#include cdio/sector.h
+#endif
DTSCDDACodec::DTSCDDACodec() : DTSCodec()
{
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#570611: ITP: mythtv -- A personal video recorder application
On Friday 16 April 2010 08:11:47 Fabian Greffrath wrote: Am 20.02.2010 07:25, schrieb Andres Mejia: Package: wnpp Severity: wishlist Owner: Andres Mejiamcita...@gmail.com * Package name: mythtv Version : 0.22 Any news on this one? Yes, the patch I proposed was rejected upstream. After some thought, even I thought having mythtv without libmp3lame would be rather useless. Perhaps general encoding done via ffmpeg can be supported, for cases where recording via vp8/theora+vorbis is desired. -- Regards, Andres Mejia ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Verbose build log
On Thu, Jun 10, 2010 at 10:12, Christophe Mutricy xto...@chewa.net wrote: Hello, VLC 1.1.0 uses automake 1.11 and so the build can produce non-verbose logs like the kernel does for some years. CC foo.o CCLD foo.so ... We can revert to the old fully verbose behaviour if we like. Do you know if there is a Debian or pkg-multimedia policy/best-practice on this matter. Verbose log can help debug FTBFS but increase the size of the log by 2 or 3 order of magnitude I would think the time you waste by waiting a 3Mb file to download instead of a 3Kb file is more than regained by the detailed command lines which could provide help with problematic flags. It's still your call, though. I don't believe there is any policy on this matter. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Verbose build log
On Thu, Jun 10, 2010 at 02:15:05PM -0400, Felipe Sateler wrote: On Thu, Jun 10, 2010 at 10:12, Christophe Mutricy xto...@chewa.net wrote: Hello, VLC 1.1.0 uses automake 1.11 and so the build can produce non-verbose logs like the kernel does for some years. CC foo.o CCLD foo.so ... We can revert to the old fully verbose behaviour if we like. Do you know if there is a Debian or pkg-multimedia policy/best-practice on this matter. Verbose log can help debug FTBFS but increase the size of the log by 2 or 3 order of magnitude I would think the time you waste by waiting a 3Mb file to download instead of a 3Kb file is more than regained by the detailed command lines which could provide help with problematic flags. It's still your call, though. I don't believe there is any policy on this matter. Debian Policy is based on common practices, not the other way around. I guess you are right, Felipe, that this is not governed by policy, but only because not yet written: I do believe it is a common practice to avoid build noise silencers. Here's one small piece of the puzzle: http://bugs.debian.org/551453 You can probably find some debates with varying viewpoints by searching debian-de...@lists.debian.org if not convinced as easy as I was :-) Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: csound manual
On Thu, Jun 10, 2010 at 18:12, Felipe Sateler fsate...@gmail.com wrote: On Thu, Jun 10, 2010 at 18:00, Jonas Smedegaard jo...@jones.dk wrote: Please see http://www.csounds.com/manual/html/PrefaceHistory.html for a short summary of the csound manual. And BTW, there is code in debian/rules that parses that page to generate a non exhaustive list of contributors. It is currently commented out, though. It is in common-post-build-indep. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
ir behold, If
pyric.rtf Description: Binary data ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Verbose build log
On Thu, Jun 10, 2010, Christophe Mutricy wrote: We can revert to the old fully verbose behaviour if we like. Do you know if there is a Debian or pkg-multimedia policy/best-practice on this matter. Verbose log can help debug FTBFS but increase the size of the log by 2 or 3 order of magnitude I understand the best practice is to use verbose build logs for package builds so that we can still grep them for flags and the like. -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#562860: mediatomb_0.12.0~svn2018-4: does not build - dh_install: command returned error code 256
I had this problem too, my debhelper needed upgrading to 7.0.50, so I upgraded to 7.4.11~bpo50+1 from lenny-backports. Worked fine after that. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#488226: Vate-detective agencies, nothing had been
tournament.rtf Description: Binary data ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: csound manual
On Thu, Jun 10, 2010 at 04:59:35PM -0400, Felipe Sateler wrote: On Thu, Jun 10, 2010 at 16:51, Jonas Smedegaard jo...@jones.dk wrote: You write to me personally, even though the packaging has now moved to the Multimedia team. Was that intentional? No, it was not. Just force of habit, i think. :-) On Thu, Jun 10, 2010 at 04:35:27PM -0400, Felipe Sateler wrote: On Tue, May 25, 2010 at 15:44, Jonas Smedegaard d...@jones.dk wrote: On Tue, May 25, 2010 at 01:37:28PM -0400, Felipe Sateler wrote: May I ask you update that please? I updated the manual to version 5.12 a couple of weeks ago, the changes are in the git repository. Maybe then we can release the updated manual? Updated now. But please check the changes to copyright_hints, like this: QUILT_PATCHES=debian/patches quilt push -a DEB_MAINTAINER_MODE=1 debian/rules pre-build DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean QUILT_PATCHES=debian/patches quilt pop -a mv debian/copyright_newhints debian/copyright_hints git diff --color-words ...or however you want to do the last part. It seems at least Michael Gogins has newly appeared. Michael Gogins has since a long time authored manual entries. He just appeared in the copyright hints, it seems. How do you mean he just appeared? That he is really not a copyright holder and it is wrong that his name appeared there? He just appeared in some file, thus detected by the copyright script. He appeared as a copyright holder, I believe, so something that we should document IMHO: Copyright 2004-2005 by Michael Gogins for modifications made to the Alternative Csound Reference Manual ...except off course if that mentioned Alternative Csound Reference Manual is not at all included in any of our source or binary packages. However, note that currently we have everything as copyright Andres Cabrera and others. Upstream is not really thorough in tracking copyrights, so trying to work out which file was authored by which set of people is not something I think is a reasonable use of anyone's time. I don't find it acceptable for us to just use the joker term and others as upstram author. If we cannot locate upstream authors, then we cannot locate the ones granting us the free license, which means we really did not receive that license and cannot redistribute. And did you check thoroughly? I just mentioned his name as an example - I believe there were more differences than that. There are many new files, and I do not track each one to see if a new copyright holder appears. However, I do follow upstream's list, and the license has not changed for the manual, which means contributions to the manual are licensed as GFDL. Upstream are in a different position than us. Them choosing to be more relaxed in how they express copyright and licensing does not permit us to do the same. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: csound manual
On Thu, Jun 10, 2010 at 18:00, Jonas Smedegaard jo...@jones.dk wrote: On Thu, Jun 10, 2010 at 04:59:35PM -0400, Felipe Sateler wrote: On Thu, Jun 10, 2010 at 16:51, Jonas Smedegaard jo...@jones.dk wrote: You write to me personally, even though the packaging has now moved to the Multimedia team. Was that intentional? No, it was not. Just force of habit, i think. :-) On Thu, Jun 10, 2010 at 04:35:27PM -0400, Felipe Sateler wrote: On Tue, May 25, 2010 at 15:44, Jonas Smedegaard d...@jones.dk wrote: On Tue, May 25, 2010 at 01:37:28PM -0400, Felipe Sateler wrote: May I ask you update that please? I updated the manual to version 5.12 a couple of weeks ago, the changes are in the git repository. Maybe then we can release the updated manual? Updated now. But please check the changes to copyright_hints, like this: QUILT_PATCHES=debian/patches quilt push -a DEB_MAINTAINER_MODE=1 debian/rules pre-build DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean QUILT_PATCHES=debian/patches quilt pop -a mv debian/copyright_newhints debian/copyright_hints git diff --color-words ...or however you want to do the last part. It seems at least Michael Gogins has newly appeared. Michael Gogins has since a long time authored manual entries. He just appeared in the copyright hints, it seems. How do you mean he just appeared? That he is really not a copyright holder and it is wrong that his name appeared there? He just appeared in some file, thus detected by the copyright script. He appeared as a copyright holder, I believe, so something that we should document IMHO: Copyright 2004-2005 by Michael Gogins for modifications made to the Alternative Csound Reference Manual ...except off course if that mentioned Alternative Csound Reference Manual is not at all included in any of our source or binary packages. His name appears in a non exhaustive list, and it happens to appear because someone actually typed his real name instead of using the corresponding XML entity, which is normally used. However, note that currently we have everything as copyright Andres Cabrera and others. Upstream is not really thorough in tracking copyrights, so trying to work out which file was authored by which set of people is not something I think is a reasonable use of anyone's time. I don't find it acceptable for us to just use the joker term and others as upstram author. If we cannot locate upstream authors, then we cannot locate the ones granting us the free license, which means we really did not receive that license and cannot redistribute. The fact that I can't remember who did what does not mean that I have not enforced contributions to be GFDL. So your reasoning is wrong. Please see http://www.csounds.com/manual/html/PrefaceHistory.html for a short summary of the csound manual. And did you check thoroughly? I just mentioned his name as an example - I believe there were more differences than that. There are many new files, and I do not track each one to see if a new copyright holder appears. However, I do follow upstream's list, and the license has not changed for the manual, which means contributions to the manual are licensed as GFDL. Upstream are in a different position than us. Them choosing to be more relaxed in how they express copyright and licensing does not permit us to do the same. In the current form, we are not in violation of the license. What do you mean we need to be more strict? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: csound manual
On Thu, Jun 10, 2010 at 06:14:22PM -0400, Felipe Sateler wrote: On Thu, Jun 10, 2010 at 18:12, Felipe Sateler fsate...@gmail.com wrote: On Thu, Jun 10, 2010 at 18:00, Jonas Smedegaard jo...@jones.dk wrote: Please see http://www.csounds.com/manual/html/PrefaceHistory.html for a short summary of the csound manual. And BTW, there is code in debian/rules that parses that page to generate a non exhaustive list of contributors. It is currently commented out, though. It is in common-post-build-indep. I lost you here. What is it you are trying to say? You insist that it is ok to cover most authors as and others instead of listing their names explicitly in debian/copyright, yet you ask me to go investigate the details. Why? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Ced entirely impracticable. Now, however
reinstates.rtf Description: Binary data ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
