Bug#886603: libgig: FTBFS: fatal error: linux/cdrom.h: No such file or directory
Source: libgig Version: 4.1.0~repack-2 Severity: important Justification: fails to build from source (but built successfully in the past) User: debian-h...@lists.debian.org Usertags: hurd-i386 Builds of libgig 4.x for hurd-i386 and kfreebsd-* (admittedly not release architectures) have been failing: Akai.h:56:11: fatal error: linux/cdrom.h: No such file or directory If you can get libgig to work reasonably well on either or both architectures without this header, please do so. Otherwise, please formally restrict its Architecture field so that autobuilders for unsupported architectures don't bother trying to cover it. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#886430: iem-plugin-suite FTBFS on !amd64/x32
Source: iem-plugin-suite Version: 1.0.1-2 Followup-For: Bug #886430 FTR, there is also a (non-release) kfreebsd-amd64 architecture on which this package could conceivably build as is. If you go for the architecture-restriction approach, please account for that possibility. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#886375: klystrack: FTBFS (32-bit): error: cast to pointer from integer of different size
Source: klystrack Version: 0.20171212-1 Severity: important Tags: upstream Justification: fails to build from source Builds of klystrack for most 32-bit architectures (with the notable exception of *i386, which I presume it special-cases) have been failing with ../klystron/src/macros.h:97:21: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] #define MAKEPTR(x) ((void*)(Uint64)(x)) in multiple contexts. Could you please take a look? I'd suggest using uintptr_t for an unsigned integral type that's the same width as a pointer. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#885249: yoshimi: FTBFS on hurd-i386: PATH_MAX undeclared
Source: yoshimi Version: 1.5.6-2 Severity: important Tags: upstream Justification: fails to build from source User: debian-h...@lists.debian.org Usertags: hurd-i386 Builds of yoshimi for hurd-i386 (admittedly not a release architecture) have been failing: /<>/src/Misc/MiscFuncs.cpp: In member function 'std::__cxx11::string MiscFuncs::localPath(std::__cxx11::string)': /<>/src/Misc/MiscFuncs.cpp:343:29: error: 'PATH_MAX' was not declared in this scope The Hurd notoriously has no static PATH_MAX. Best practice is to accommodate whatever you actually encounter (with the help of, e.g., the GNU libc extension get_current_dir_name); alternatively, you can look up _PC_PATH_MAX via pathconf or supply a fallback constant (traditionally 4096). Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#882454: gerbera: FTBFS on hurd-i386: Gerbera was unable to deterimine the host OS.
Source: gerbera Version: 1.1.0+dfsg-2 Severity: important Tags: upstream Justification: fails to build from source User: debian-h...@lists.debian.org Usertags: hurd-i386 Builds of gerbera for hurd-i386 (admittedly not a release architecture) have been failing per the below excerpt from https://buildd.debian.org/status/fetch.php?pkg=gerbera=hurd-i386=1.1.0%2Bdfsg-2=1511312309=0: CMake Error at CMakeLists.txt:314 (message): Gerbera was unable to deterimine the host OS. Please report this. Value of CMAKE_SYSTEM_NAME: GNU Could you please take a look? With any luck, the Linux settings will make a decent starting point. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#882188: juce: FTBFS on non-Linux: sys/prctl.h: No such file or directory
"Aaron M. Ucko" <u...@debian.org> writes: > However, there may well be additional portability issues; in > particular, I see that libopenshot-audio FTBFS on hurd-i386 due to > errors in "JuceLibraryCode". (I'll report that failure separately.) Rather, I already did (as #876792); likewise, #876793 corresponds to #882189. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#882189: juce: FTBFS on m68k: StringHolder is not large enough to hold an empty String
Source: juce Version: 5.2.0~repack-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-m...@lists.debian.org Usertags: m68k Builds of juce for m68k (admittedly not a release architecture) have been failing: ../../../../modules/juce_core/text/juce_String.cpp:233:9: error: static assertion failed: StringHolder is not large enough to hold an empty String I presume Atomic needs a separate lock on this architecture. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#882188: juce: FTBFS on non-Linux: sys/prctl.h: No such file or directory
Source: juce Version: 5.2.0~repack-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-h...@lists.debian.org Usertags: hurd-i386 Builds of juce for hurd-i386 and kfreebsd-* (admittedly not release architectures) have been failing. The immediate problem is ../../../../modules/juce_core/native/juce_BasicNativeHeaders.h:232:11: fatal error: sys/prctl.h: No such file or directory However, there may well be additional portability issues; in particular, I see that libopenshot-audio FTBFS on hurd-i386 due to errors in "JuceLibraryCode". (I'll report that failure separately.) Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#879075: libopenshot: FTBFS on mips, s390x, and hppa with identical errors
"Aaron M. Ucko" <u...@debian.org> writes: > https://buildd.debian.org/status/fetch.php?pkg=libopenshot=mips=0.1.8%2Bds1-1=1508344748=0 > https://buildd.debian.org/status/fetch.php?pkg=libopenshot=s390x=0.1.8%2Bds1-1=1508343103=0 > https://buildd.debian.org/status/fetch.php?pkg=libopenshot=hppa=0.1.8%2Bds1-1=1508361036=0 FWIW, I see identical errors on armel, armhf, and mips64el, for which builds were presumably still in progress when I originally filed this report. https://buildd.debian.org/status/fetch.php?pkg=libopenshot=armel=0.1.9%2Bdfsg1-1=1510918109=0 https://buildd.debian.org/status/fetch.php?pkg=libopenshot=armhf=0.1.9%2Bdfsg1-1=1510917203=0 https://buildd.debian.org/status/fetch.php?pkg=libopenshot=mips64el=0.1.9%2Bdfsg1-1=1510930991=0 Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#880851: libva: FTBFS on non-Linux: __NR_gettid undeclared
Sebastian Ramacher <sramac...@debian.org> writes: > Dear kfreebsd-porters, could you have a look at that issue? I'm not an official porter for any architecture, but last I heard, the (k)FreeBSD system call corresponding to gettid was thr_self, as discussed on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725383. As for hurd-i386, if and when it becomes relevant, you should be able to use mach_thread_self, which however requires some additional reference-count bookkeeping logic. Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875456 (and disregard my initial suggestion there to fall back on pthread_self, since pthread_t is officially opaque). Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#880851: libva: FTBFS on non-Linux: __NR_gettid undeclared
Source: libva Version: 1.8.3-2 Severity: important Tags: upstream Justification: fails to build from source (but built successfully in the past) User: debian-...@lists.debian.org Usertags: kfreebsd Builds of libva for kfreebsd-* (admittedly not release architectures) have been failing lately: va_trace.c: In function 'add_trace_config_info': va_trace.c:294:28: error: '__NR_gettid' undeclared (first use in this function); did you mean '__getpgid'? pid_t thd_id = syscall(__NR_gettid); (plus a few more uses further down in va_trace.c). Builds for hurd-i386 (not a release architecture) are blocked on the unavailability of libdrm-dev there, but will presumably encounter the same error if and when it ever becomes available. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#879076: libopenshot: FTBFS on ppc64(el) and powerpc: several tests report discrepancies
Source: libopenshot Version: 0.1.8+ds1-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-powe...@lists.debian.org Builds of libopenshot for ppc64el and the non-release architectures powerpc and ppc64 have been failing with mostly identical errors, as detailed at https://buildd.debian.org/status/fetch.php?pkg=libopenshot=ppc64el=0.1.8%2Bds1-1=1508343041=0 https://buildd.debian.org/status/fetch.php?pkg=libopenshot=powerpc=0.1.8%2Bds1-1=1508342906=0 https://buildd.debian.org/status/fetch.php?pkg=libopenshot=ppc64=0.1.8%2Bds1-1=1508342970=0 The only difference in errors between the architectures is that on ppc64, FFmpegReader_Check_Video_File crashes (at line 82) before it can report any errors, as does FFmpegWriter_Test_Webm (which is otherwise successful). Apart from that, there are a total of 29 discrepancies across the tests Clip_Effects, FFmpegReader_Check_Video_File, ImageWriter_Test_Gif, and Timeline_Check_Two_Track_Video. In Clip_Effects, three values that should be 255 come out 239, and three that should be 0 come out 16. (NB: 16 + 239 = 255.) In FFmpegReader_Check_Video_File (when it doesn't crash altogether), five values come out somewhat greater than expected. In ImageWriter_Test_Gif and Timeline_Check_Two_Track_Video, a number of values come out 0 -- four in ImageWriter_Test_Gif and fourteen in Timeline_Check_Two_Track_Video. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#879075: libopenshot: FTBFS on mips, s390x, and hppa with identical errors
Source: libopenshot Version: 0.1.8+ds1-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-m...@lists.debian.org Builds of libopenshot for mips, s390x, and the non-release architecture hppa all failed with identical errors in the tests FFmpegReader_Check_Video_File, ImageWriter_Test_Gif, and Timeline_Check_Two_Track_Video, as detailed at https://buildd.debian.org/status/fetch.php?pkg=libopenshot=mips=0.1.8%2Bds1-1=1508344748=0 https://buildd.debian.org/status/fetch.php?pkg=libopenshot=s390x=0.1.8%2Bds1-1=1508343103=0 https://buildd.debian.org/status/fetch.php?pkg=libopenshot=hppa=0.1.8%2Bds1-1=1508361036=0 There are a total of 14 individual errors, in all cases of a value being slightly different from what was expected (sometimes high, sometimes low), and a bunch of warnings, mostly along the lines of [swscaler @ 0x69600610] No accelerated colorspace conversion found from yuv420p to rgba. The report for line 122 of Timeline_Tests.cpp reports the actual value as a control character rather than a number, presumably because the variable being checked has type char (or a variant thereof). Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#879074: libopenshot: FTBFS on arm64: several tests report discrepancies
Source: libopenshot Version: 0.1.8+ds1-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-...@lists.debian.org Builds of libopenshot for arm64 have been failing with errors in the tests FFmpegReader_Check_Video_File, ImageWriter_Test_Gif, and Timeline_Check_Two_Track_Video, as detailed at https://buildd.debian.org/status/fetch.php?pkg=libopenshot=arm64=0.1.8%2Bds1-1=1508343146=0 There are a total of 21 individual errors, in all cases of a value being somewhat greater than expected, and a bunch of warnings, mostly along the lines of [swscaler @ 0x64384ad0] No accelerated colorspace conversion found from yuv420p to rgba. The report for line 122 of Timeline_Tests.cpp reports the actual value as a control character rather than a number, presumably because the variable being checked has type char (or a variant thereof). Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#877799: groovy: GCJ java.lang.ArrayIndexOutOfBoundsException
Emmanuel Bourg <ebo...@apache.org> writes: > versioned dependency on default-jre-headless to avoid this situation, > I'll fix that in the next upload. Great, thanks! > Regarding Kodi I suggest compiling the Groovy files in the arch indep > part of the build, such that hppa doesn't have to deal with the Java > stuff, only the native part. Copying Kodi's maintainers per this advice. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#877798: kodi: FTBFS on alpha: tests don't start
Source: kodi Version: 2:17.3+dfsg1-3 Severity: important Tags: upstream Justification: fails to build from source (but built successfully in the past) User: debian-al...@lists.debian.org The latest build of kodi for alpha (admittedly not a release architecture) failed: [==] Running 582 tests from 91 test cases. [--] Global test environment set-up. E: Build killed with signal TERM after 150 minutes of inactivity Judging from other architectures' and versions' build logs, the test suite normally reports detailed progress, so I gather that in this case, it hanged at startup for some reason. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#876793: libopenshot-audio: FTBFS on m68k: EmptyString and StringHolder differ in size
Source: libopenshot-audio Version: 0.1.4+ds1-2 Severity: important Tags: upstream Justification: fails to build from source User: debian-m...@lists.debian.org Builds of libopenshot-audio for m68k (admittedly not a release architecture) have been failing: ./../../modules/juce_core/text/juce_String.cpp: In member function 'void juce::StringHolder::compileTimeChecks()': ./../../modules/juce_core/system/juce_PlatformDefs.h:179:38: error: static assertion failed: sizeof (EmptyString) == sizeof (StringHolder) Atomic<> evidently imposes a size overhead here. :-/ Could you please take a look? Incidentally, you really ought to look into building against separately packaged juce per Policy 4.13, but it also FTBFS on m68k (and on non-Linux, as in #876792), so that wouldn't actually help here. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#876792: libopenshot-audio: FTBFS on non-Linux: multiple identifiers undeclared
Source: libopenshot-audio Version: 0.1.4+ds1-2 Severity: important Tags: upstream Justification: fails to build from source User: debian-h...@lists.debian.org Builds of libopenshot-audio for hurd-i386 (admittedly not a release architecture) have been failing. The (immediate) errors are /<>/libopenshot-audio-0.1.4+ds1/JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:906:6: error: 'pthread_setname_np' was not declared in this scope /<>/libopenshot-audio-0.1.4+ds1/JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:961:5: error: 'pthread_setaffinity_np' was not declared in this scope /<>/libopenshot-audio-0.1.4+ds1/JuceLibraryCode/modules/juce_core/native/juce_linux_SystemStats.cpp:98:20: error: aggregate 'juce::SystemStats::getMemorySizeInMegabytes()::sysinfo sysi' has incomplete type and cannot be defined Builds for kFreeBSD (not a release architecture either) have been failing in a similar fashion, as most recently detailed at https://buildd.debian.org/status/fetch.php?pkg=libopenshot-audio=kfreebsd-amd64=0.1.4%2Bds1-1=1498606847=0 https://buildd.debian.org/status/fetch.php?pkg=libopenshot-audio=kfreebsd-i386=0.1.4%2Bds1-1=1498005708=0 (The kFreeBSD autobuilders haven't covered 0.1.4+ds1-2 because cmake is currently uninstallable there.) Could you please take a look? If making the code more portable is infeasible, please consider restricting the package's architecture to linux-any so that non-Linux autobuilders don't bother trying to cover it. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#863109: iannix: FTBFS on armel and armhf: mixes double and qreal
notfixed 863109 0.9.17~dfsg0-2 found 863109 0.9.17~dfsg0-2 thanks Thanks for looking into this bug. Builds on these architectures now make more progress, but still fail due to discrepancies between qreal (float) and mu::value_type (double). Could you please take another look? Also, I see the same errors on the (non-release) sh4 architecture, so please extend any architecture-based special casing accordingly. https://buildd.debian.org/status/fetch.php?pkg=iannix=armel=0.9.17%7Edfsg0-2=1496698963=0 https://buildd.debian.org/status/fetch.php?pkg=iannix=armhf=0.9.17%7Edfsg0-2=1496699440=0 https://buildd.debian.org/status/fetch.php?pkg=iannix=sh4=0.9.17%7Edfsg0-2=1496701904=0 Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#863109: iannix: FTBFS on armel and armhf: mixes double and qreal
Source: iannix Version: 0.9.17~dfsg0-1 Severity: important Justification: fails to build from source Builds of iannix for armel and armhf have been failing due to incorrectly assuming qreal to be equivalent to double; for historical reasons, it is instead float on both of those architectures. For more details, please see the logs: https://buildd.debian.org/status/fetch.php?pkg=iannix=armel=0.9.17~dfsg0-1=1495369545=0 https://buildd.debian.org/status/fetch.php?pkg=iannix=armhf=0.9.17~dfsg0-1=1495369249=0 Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#861711: buildd.debian.org: Architecture: all B-D confusion
Package: buildd.debian.org Severity: serious Justification: makes some packages fail to build from source Per https://buildd.debian.org/status/package.php?p=gsequencer=sid , gsequencer shows up as BD-Uninstallable for Architecture: all with the explanation gsequencer build-depends on missing: - liboss4-salsa-dev:amd64 gsequencer specifies an appropriate architecture restriction here: Build-Depends: debhelper (>= 10), autotools-dev, dh-autoreconf, pkg-config, libcunit1-dev, libgtk2.0-dev, libcairo2-dev, xvfb, xauth, libx11-dev, libinstpatch-dev, libsndfile1-dev, libsamplerate-dev, libxml2-dev, ladspa-sdk, dssi-dev, lv2-dev, libgmp-dev, libasound2-dev [linux-any], liboss4-salsa-dev [!linux-any], oss4-dev [kfreebsd-any], libjack-dev, uuid-dev, docbook-xsl, docbook-xml, gtk-doc-tools, xsltproc Its maintainers could probably stand to split out B-D-Arch and B-D-Indep settings, but my understanding is that the Architecture: all build should have been able to proceed regardless; it certainly did in the past. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#846499: qstopmotion: FTBFS: tries to compare va_list to NULL
Source: qstopmotion
Version: 2.3.2-1
Severity: important
Justification: fails to build from source
Builds of qstopmotion on platforms (arm64 so far) on which va_list
isn't simply a pointer have been failing:
/«PKGBUILDDIR»/src/technical/grabber/gphoto2/gpgrabber.cpp: In static member
function 'static void GphotoGrabber::errorDumper(GPLogLevel, const char*, const
char*, va_list, void*)':
/«PKGBUILDDIR»/src/technical/grabber/gphoto2/gpgrabber.cpp:814:17: warning:
NULL used in arithmetic [-Wpointer-arith]
if (args != NULL) {
^~~~
/«PKGBUILDDIR»/src/technical/grabber/gphoto2/gpgrabber.cpp:814:14: error:
invalid operands of types 'va_list {aka __va_list}' and 'long int' to binary
'operator!='
if (args != NULL) {
^
CMakeFiles/qstopmotion.dir/build.make:1817: recipe for target
'CMakeFiles/qstopmotion.dir/src/technical/grabber/gphoto2/gpgrabber.cpp.o'
failed
In general, it's best practice to treat va_list as an opaque type and
avoid making any assumptions about its form.
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
___
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#844464: kodi: FTBFS on mips(el): undefined gl* and egl* symbols
Source: kodi Version: 17.0~beta5+dfsg1-3 Severity: serious Justification: fails to build from source (but built successfully in the past) The mips and mipsel builds of kodi failed with undefined references to gl* and egl* symbols, per the log excerpt below. Could you please take a look? Thanks! xbmc/windowing/X11/windowing_X11.a(GLContextEGL.o): In function `CGLContextEGL::Destroy()': ./xbmc/windowing/X11/GLContextEGL.cpp:253: undefined reference to `eglTerminate' ./xbmc/windowing/X11/GLContextEGL.cpp:255: undefined reference to `eglTerminate' xbmc/windowing/X11/windowing_X11.a(GLContextEGL.o): In function `CGLContextEGL::QueryExtensions()': ./xbmc/windowing/X11/GLContextEGL.cpp:369: undefined reference to `eglQueryString' ./xbmc/windowing/X11/GLContextEGL.cpp:369: undefined reference to `eglQueryString' xbmc/windowing/X11/windowing_X11.a(GLContextEGL.o): In function `CGLContextEGL::Refresh(bool, int, unsigned long, bool&)': ./xbmc/windowing/X11/GLContextEGL.cpp:159: undefined reference to `eglTerminate' ./xbmc/windowing/X11/GLContextEGL.cpp:159: undefined reference to `eglTerminate' xbmc/cores/VideoPlayer/VideoRenderers/VideoRenderer.a(FrameBufferObject.o): In function `CFrameBufferObject::BindToTexture(unsigned int, unsigned int)': ./xbmc/cores/VideoPlayer/VideoRenderers/FrameBufferObject.cpp:134: undefined reference to `glCheckFramebufferStatusEXT' ./xbmc/cores/VideoPlayer/VideoRenderers/FrameBufferObject.cpp:134: undefined reference to `glCheckFramebufferStatusEXT' collect2: error: ld returned 1 exit status -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#844028: jsusfx: FTBFS (32-bit): tries to use bad 32-bit x86 assembly
Source: jsusfx Version: 0.3.1-1 Severity: important Justification: fails to build from source Builds of jsusfx for 32-bit architectures have been failing due to the attempted use of WDL/eel2/glue_x86.h, which turns out not to work even on *i386 or x32. 64-bit builds all nominally succeed, but those for non-amd64 processors almost certainly yield broken executables, since they all (regardless of actual processor type) use glue_x86_64.h, which uses raw machine code throughout. I would recommend * Using glue_x86_64.h only on actual x86_64 * Fixing glue_x86.h and using it only on *i386 and possibly x32. * Using glue_ppc.h on powerpc, as presumably intended. Its usage is conditional on __ppc__, but at least on Linux, the relevant predefined macro would be __powerpc__. You might need to exclude __powerpc64__ and/or _LITTLE_ENDIAN for correct results. * Actually using the fallback glue_port.h elsewhere. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#842822: pd-ableton-link: FTBFS on s390x: R_390_GOT12 relocations truncated to fit
Source: pd-ableton-link
Version: 0.2-1
Severity: important
Justification: fails to build from source
The s390x build of pd-ableton-link failed:
g++ -DPD -I "/usr/include/pd" -DUNIX -Wdate-time -D_FORTIFY_SOURCE=2 -fpic
-fcheck-new -I/usr/include/ableton -std=c++11 -Wno-multichar
-DLINK_PLATFORM_LINUX=1 -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=.
-fstack-protector-strong -Wformat -Werror=format-security -o abl_link~.o -c
abl_link~.cpp
info: making abl_link_instance.o in lib abl_link~
g++ -DPD -I "/usr/include/pd" -DUNIX -Wdate-time -D_FORTIFY_SOURCE=2 -fpic
-fcheck-new -I/usr/include/ableton -std=c++11 -Wno-multichar
-DLINK_PLATFORM_LINUX=1 -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=.
-fstack-protector-strong -Wformat -Werror=format-security -o
abl_link_instance.o -c abl_link_instance.cpp
info: linking objects in abl_link~.pd_linux for lib abl_link~
g++ -rdynamic -shared -fpic -Wl,-rpath,"\$ORIGIN",--enable-new-dtags
-Wl,-z,relro -o abl_link~.pd_linux abl_link~.o abl_link_instance.o -lc -lm
-lstdc++
abl_link_instance.o: In function
`std::_Function_base::_Base_manager<ableton::Link::Link(double)::{lambda(unsigned
long)#3}>::_M_manager(std::_Any_data&,
std::_Function_base::_Base_manager<ableton::Link::Link(double)::{lambda(unsigned
long)#3}> const&, std::_Manager_operation)':
/usr/include/c++/6/functional:1607:(.text._ZNSt14_Function_base13_Base_managerIZN7ableton4LinkC4EdEUlmE1_E10_M_managerERSt9_Any_dataRKS5_St18_Manager_operation[_ZNSt14_Function_base13_Base_managerIZN7ableton4LinkC4EdEUlmE1_E10_M_managerERSt9_Any_dataRKS5_St18_Manager_operation]+0x3a):
relocation truncated to fit: R_390_GOT12 against symbol `typeinfo for
ableton::Link::Link(double)::{lambda(unsigned long)#3}' defined in
.data.rel.ro._ZTIZN7ableton4LinkC4EdEUlmE1_[_ZTIZN7ableton4LinkC4EdEUlmE1_]
section in abl_link_instance.o
[...]
abl_link_instance.o: In function `__static_initialization_and_destruction_0':
/usr/include/c++/6/iostream:74:(.text.startup+0x6c): relocation truncated to
fit: R_390_GOT12 against symbol `std::ios_base::Init::~Init()@@GLIBCXX_3.4'
defined in .text section in /usr/lib/gcc/s390x-linux-gnu/6/libstdc++.so
abl_link~.o: In function `__static_initialization_and_destruction_0':
/usr/include/c++/6/iostream:74:(.text.startup+0x7a): additional relocation
overflows omitted from the output
collect2: error: ld returned 1 exit status
Could you please take a look? It might help to substitute -fPIC (note
capitalization) for -fpic, which limits global offset table size on
some architectures.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
___
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#842653: ableton-link: FTBFS on non-Linux: htonll/ntohll undeclared
Source: ableton-link Version: 1.0.0+dfsg-2 Severity: important Tags: upstream Justification: fails to build from source Thanks for taking care of #842410 promptly! ableton-link now builds on all Linux architectures, but fails on kFreeBSD and the Hurd: /«BUILDDIR»/ableton-link-1.0.0+dfsg/include/ableton/discovery/NetworkByteStreamSerializable.hpp:204:41: error: 'htonll' was not declared in this scope return detail::copyToByteStream(htonll(ll), std::move(out)); The problem appears to be that there's no definition of htonll for generic POSIX systems, just for Linux and other specific OSes. I'd recommend arranging to use bswap_64 on all systems using the GNU C Library (whose headers define __GLIBC__). Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#842410: ableton-link: FTBFS: -m64 considered harmful
Source: ableton-link Version: 1.0.0+dfsg-1 Severity: important Justification: fails to build from source Builds of ableton-link for most architectures failed due to its explicit use of -m64. This option is appropriate for Debian package builds only in very specialized circumstances, since the compiler already targets the system's native architecture by default; please fix the build system not to supply -m64 at all. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#839952: libambix: FTBFS on *i386: basic2extended_identity4x4_float32__{f64, i32} fail
Source: libambix
Version: 0.1-1
Severity: important
Justification: fails to build from source
Builds of libambix for i386 and the non-release architectures
hurd-i386 and kfreebsd-i386 all failed because the
basic2extended_identity4x4_float32__{f64,i32} tests both did (along
with the matrix test, reported separately just now as #839950). Could
you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
___
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#839950: libambix: FTBFS: matrix test fails
Source: libambix Version: 0.1-1 Severity: important Justification: fails to build from source Builds of libambix for several architectures failed due to an error in the matrix test. These builds didn't log further details, but I presume you should be able to reproduce the error on a porterbox. FWIW, the architectures that failed so far in this fashion are arm64, i386, powerpc, ppc64, and s390x, plus the non-release architectures hurd-i386, kfreebsd-i386, and ppc64. However, builds for several more architectures are still pending, so the problem may turn out to be somewhat wider. The *i386 builds also encountered two other test suite errors, which I'll report separately since they have not (so far) occurred elsewhere. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#836410: libhdcd: FTBFS on *i386: analyzer-lle md5_result wrong
Source: libhdcd Version: 1.0~rc0-1 Severity: important Justification: fails to build from source The builds of libhdcd on i386 and hurd-i386 failed with identical test suite errors, which I presume the kfreebsd-i386 build will also encounter in due course: analyzer-lle: 1c1 < 323eb974ded55b7528efb237fa694301 --- > cbec0b7d20475c4c0b0e341e3b354bd4 -- FAILED [md5_result] ./tests.sh: line 28: exit: EXIT_CODE: numeric argument required (As you can see, there also appears to be a typo in the test harness's error-handling logic, but that's a secondary concern.) Builds for all other architectures have been successful so far, even x32. Could you please take a look? Thanks! ___ 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#836328: gsequencer: FTBFS on non-Linux: ALSA too old (1.0.5 vs. 1.0.25)
Source: gsequencer Version: 0.7.62-1 Severity: important Justification: fails to build from source Builds of gsequencer on kFreeBSD and the Hurd failed: checking for LIBASOUND2... no configure: error: Package requirements (alsa >= 1.0.25) were not met: Requested 'alsa >= 1.0.25' but version of alsa is 1.0.5 Please either accommodate the (emulated, IIRC) version of ALSA available there or version the build dependency on libasound2-dev appropriately. Thanks! ___ 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#836327: gsequencer: FTBFS on mips and powerpc: ags_functional_audio_test segmentation fault
Source: gsequencer Version: 0.7.62-1 Severity: serious Justification: fails to build from source (but built successfully in the past) The latest builds of gsequencer for mips and powerpc both failed because ags_functional_audio_test segfaulted: https://buildd.debian.org/status/fetch.php?pkg=gsequencer=mips=0.7.62-1=1472716604 https://buildd.debian.org/status/fetch.php?pkg=gsequencer=powerpc=0.7.62-1=1472714618 Could you please take a look? Thanks! ___ 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#836326: gsequencer: FTBFS on i386: ags_channel_test segmentation fault
Source: gsequencer Version: 0.7.62-1 Severity: serious Justification: fails to build from source (but built successfully in the past) The latest i386 build of gsequencer failed because ags_channel_test crashed. Could you please take a look? Thanks! PASS: ags_thread_test PASS: ags_audio_test ./test-driver: line 107: 9968 Segmentation fault "$@" > $log_file 2>&1 FAIL: ags_channel_test PASS: ags_recycling_test PASS: ags_audio_signal_test PASS: ags_recall_test PASS: ags_pattern_test PASS: ags_notation_test PASS: ags_automation_test PASS: ags_functional_audio_test = gsequencer 0.7.62: ./test-suite.log = # TOTAL: 10 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: ags_channel_test == CUnit - A unit testing framework for C - Version 2.1-3 http://cunit.sourceforge.net/ Suite: AgsChannelTest Test: test of AgsChannel add recall ...passed Test: test of AgsChannel add recall container ...FAILED 1. ags/test/audio/ags_channel_test.c:131 - g_list_find(channel->container, recall_container) != NULL Test: test of AgsChannel add recall id ...FAILED 1. ags/test/audio/ags_channel_test.c:148 - g_list_find(channel->recall_id, recall_id) != NULL Test: test of AgsChannel add duplicate recall ...FAIL ags_channel_test (exit status: 139) ___ 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#821825: csoundqt: please split out examples
Package: csoundqt Version: 0.9.2.1-1 Severity: normal Hi, Felipe. I see that the csoundqt binary package has gained just over 70 MB of examples, which I presume are architecture-independent and not necessary to run the application. Please split these out into a dedicated Architecture: all binary package, which the main csoundqt package can list in either Recommends or Suggests (your call). Thanks! -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages csoundqt depends on: ii libc6 2.22-6 ii libcsnd6-6.0v51:6.05~dfsg1-7+b2 ii libcsound64-6.0 1:6.05~dfsg1-7+b2 ii libgcc1 1:5.3.1-14 ii libgl1-mesa-glx [libgl1] 11.1.2-1 ii libqt5concurrent5 5.5.1+dfsg-16+b1 ii libqt5core5a 5.5.1+dfsg-16+b1 ii libqt5gui55.5.1+dfsg-16+b1 ii libqt5network55.5.1+dfsg-16+b1 ii libqt5printsupport5 5.5.1+dfsg-16+b1 ii libqt5qml55.5.1-3 ii libqt5quick5 5.5.1-3 ii libqt5quickwidgets5 5.5.1-3 ii libqt5widgets55.5.1+dfsg-16+b1 ii libqt5xml55.5.1+dfsg-16+b1 ii libstdc++65.3.1-14 Versions of packages csoundqt recommends: ii csound 1:6.05~dfsg1-7+b2 pn csound-doc ii graphviz2.38.0-12+b2 csoundqt 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
Bug#814125: drumgizmo: FTBFS on non-Linux: automatic GUI detection broken
Source: drumgizmo Version: 0.9.8.1-1 Severity: important Justification: fails to build from source Builds of drumgizmo for non-Linux architectures (just kFreeBSD so far) have been failing: Auto setting gui based on host: kfreebsd-gnu configure: error: Your platform is not currently supported Please try explicitly passing --enable-gui=x11. (It looks like the upstream configure script inappropriately capitalizes BSD on line 46, and doesn't attempt to cover the Hurd at all.) Thanks! ___ 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#747540: soundscaperenderer: FTBFS on non-amd64: looks for Boost in the wrong place
Source: soundscaperenderer
Version: 0.4.1~dfsg-1
Severity: important
Justification: fails to build from source
Builds of soundscaperenderer for architectures other than amd64 have
been failing with the errors
checking for boost_system library... not found! (Use BOOST_LIB_DIR to specify
a directory.)
checking for boost_thread library... not found! (Use BOOST_LIB_DIR to specify
a directory.)
configure: error: ip-interface (network (TCP/IP) interface) not available!
Use --disable-ip-interface to deactivate.
even though soundscaperenderer properly lists libboost-system-dev and
libboost-thread-dev in Build-Depends. The problem appears to stem
from looking only in a specific set of locations, presumably to account
for possible library-name tags:
for dir in $BOOST_LIB_DIR /{usr,opt}/{local/,}lib{,64}{,/x86_64-linux-gnu}; do
I believe setting BOOST_LIB_DIR to /usr/lib/$(DEB_HOST_MULTIARCH)
should remedy that; could you please give it a try?
Thanks!
___
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#724526: ardour3: FTBFS on non-x86: xmmintrin.h: No such file or directory
Source: ardour3 Version: 3.4~dfsg-2 Severity: important Builds of ardour3 on non-x86 architectures have been failing because they still try to use x86 SSE extensions: ../libs/ardour/sse_functions_xmm.cc:21:23: fatal error: xmmintrin.h: No such file or directory I see that these builds are still running with -DBUILD_SSE_OPTIMIZATIONS for some reason; can you perhaps conditionalize this flag's use? (I'd suggest doing without it and the corresponding -m* flags on i386 as well to yield more portable binaries.) At any rate, please do take a look. Thanks! ___ 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#715573: dvbpsi-utils: dvbinfo is a libtool-generated temporary wrapper
Package: dvbpsi-utils Version: 1.0.0-2 Severity: important $ head /usr/bin/dvbinfo #! /bin/bash # dvbinfo - temporary wrapper script for .libs/dvbinfo # Generated by libtool (GNU libtool) 2.4.2 Debian-2.4.2-1.3 # # The dvbinfo program cannot be directly executed until all the libtool # libraries that it depends on are installed. # # This wrapper script should never be moved out of the build directory. # If it is, it will not operate correctly. Could you please ship the actual binary? Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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
Bug#645244: libsbsms: FTBFS on *-i386: malloc et al. used undeclared
Source: libsbsms Version: 2.0.0-1 Severity: serious Justification: fails to build from source Builds of libsbsms on i386 platforms are failing: buffer.h: In constructor '_sbsms_::RingBufferT::RingBuffer()': buffer.h:44:39: error: there are no arguments to 'calloc' that depend on a template parameter, so a declaration of 'calloc' must be available [-fpermissive] buffer.h:44:39: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) [...] Could you please arrange for buffer.h to #include stdlib.h for compatibility with recent libstdc++ versions whose headers have undergone dependency cleanup? Thanks! ___ 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#645245: libsbsms: FTBFS on non-x86: tries to build with -msse
Source: libsbsms Version: 2.0.0-1 Severity: serious Justification: fails to build from source libsbsms's upstream build system now defaults to enabling SSE support; however, that's only an option on x86, and even there Debian's *-i386 packages still need to support older processors. *-amd64 is another matter; SSE2 comes standard there, so -msse is redundant but any explicit optimizations may still be of interest. As such, please invoke configure --disable-sse unless dpkg-architecture -qDEB_HOST_ARCH_CPU yields amd64. Thanks! ___ 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#635966: lame: FTBFS in parallel (-jN): test/mkdir race condition
Source: lame Version: 3.98.4+repack2-1 Severity: serious Justification: fails to build from source The i386 build of lame (invoked with -j4) failed due to a race condition between test and mkdir: Making all in i386 make[4]: Entering directory `.../lame-3.98.4+repack2/libmp3lame/i386' test -d .libs || mkdir .libs test -d .libs || mkdir .libs test -d .libs || mkdir .libs test -d .libs || mkdir .libs mkdir: cannot create directory `.libs': File exists I'd suggest invoking mkdir with the -p flag, at which point the calls to test would be redundant. Could you please look into the matter? Thanks! -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 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 lame depends on: ii libc6 2.13-10 Embedded GNU C Library: Shared lib ii libmp3lame0 3.98.4+repack2-1 MP3 encoding library ii libncurses5 5.9-1shared libraries for terminal hand lame recommends no packages. lame 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
Bug#635966: lame: FTBFS in parallel (-jN): test/mkdir race condition
Andres Mejia mcita...@gmail.com writes: I made an upload to fix this before this bug report was submitted. This issue is fixed now. Great; thanks for promptly spotting and taking care of the problem, and sorry for the extraneous bug report. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu ___ 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#633476: yoshimi: FTBFS w/fluid 1.3: undefined references to empty functions
Source: yoshimi
Version: 0.060.10-2
Severity: important
Tags: patch
fluid 1.3.x, which is currently available in experimental and which I
plan to upload to unstable in a few days, generates somewhat different
output from 1.1.x. Most of the differences are purely formal, such
that fluid 1.3.x output is generally compatible with FLTK 1.1
development environments and vice versa. One change, however, affects
yoshimi: per http://www.fltk.org/str.php?L2259, fluid no longer
produces (empty) implementations for totally empty functions in .fl
files, of which yoshimi has a few: BankProcess_::process,
PSlider::PSlider, PartUI_::showparameters, PresetsUI_::refresh, and
PresetsUI_::~PresetsUI_.
The last of those (being non-virtual) is redundant and can go away
altogether; as for the remaining functions, you can force fluid's hand
by adding comments to their bodies. The attached patch does all of
that; could you please apply it, or let me know if you'd agree to an
NMU?
Thanks!
Index: yoshimi/src/UI/BankUI.fl
===
--- yoshimi.orig/src/UI/BankUI.fl 2011-07-10 11:30:47.0 -0400
+++ yoshimi/src/UI/BankUI.fl 2011-07-10 11:45:57.0 -0400
@@ -51,7 +51,10 @@
class BankProcess_ {open
} {
Function {process(void)} {open return_type {virtual void}
- } {}
+ } {
+comment {This body intentionally left blank.} {in_source not_in_header
+}
+ }
decl {Bank *bank;} {public
}
}
Index: yoshimi/src/UI/OscilGenUI.fl
===
--- yoshimi.orig/src/UI/OscilGenUI.fl 2011-07-10 11:30:47.0 -0400
+++ yoshimi/src/UI/OscilGenUI.fl 2011-07-10 11:42:21.0 -0400
@@ -166,7 +166,11 @@
class PSlider {open : {public Fl_Slider}
} {
- Function {PSlider(int x,int y, int w, int h, const char *label=0):Fl_Slider(x,y,w,h,label)} {} {}
+ Function {PSlider(int x,int y, int w, int h, const char *label=0):Fl_Slider(x,y,w,h,label)} {
+ } {
+comment {This body intentionally left blank.} {in_source not_in_header
+}
+ }
Function {handle(int event)} {return_type int
} {
code {int X=x(),Y=y(),W=w(),H=h();
Index: yoshimi/src/UI/PartUI.fl
===
--- yoshimi.orig/src/UI/PartUI.fl 2011-07-10 11:30:47.0 -0400
+++ yoshimi/src/UI/PartUI.fl 2011-07-10 11:46:36.0 -0400
@@ -89,7 +89,10 @@
class PartUI_ {open
} {
Function {showparameters(int kititem,int engine)} {open return_type virtual
- } {}
+ } {
+comment {This body intentionally left blank.} {in_source not_in_header
+}
+ }
}
class PartKitItem {: {public Fl_Group}
Index: yoshimi/src/UI/PresetsUI.fl
===
--- yoshimi.orig/src/UI/PresetsUI.fl 2011-07-10 11:30:47.0 -0400
+++ yoshimi/src/UI/PresetsUI.fl 2011-07-10 11:50:44.0 -0400
@@ -44,8 +44,10 @@
class PresetsUI_ {} {
Function {refresh()} {return_type {virtual void}
- } {}
- Function {~PresetsUI_()} {} {}
+ } {
+comment {This body intentionally left blank.} {in_source not_in_header
+}
+ }
}
class PresetsUI {} {
___
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#629471: ois: FTBFS: .symbols file should account for architecture differences
Package: ois Version: 1.3.0+dfsg0-2 Severity: serious Justification: fails to build from source Builds of ois are failing on most platforms due to differences in the set of symbols it defines. I see you've tried to account for some differences by specifying demangled names, but some symbols still appear to be missing altogether, per https://buildd.debian.org/status/package.php?p=ois (Also, the kFreeBSD builds are failing because there's no linux/input.h.) Could you please take a look? Thanks! -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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
Bug#627191: ecasound: FTBFS: Python tests failing
Package: ecasound Version: 2.8.0-1 Severity: serious Justification: fails to build from source Automatic builds of ecasound are failing on several architectures (i386 among them, per https://buildd.debian.org/status/fetch.php?pkg=ecasoundarch=i386ver=2.8.0-1stamp=1305671476 ) because the Python module somehow can't determine the new ecasound executable's version: Traceback (most recent call last): File ./test1_stresstest.py, line 44, in module e = ECA_CONTROL_INTERFACE(debuglevel) File .../ecasound-2.8.0/pyecasound/ecacontrol.py, line 36, in __init__ I.initialize() File .../ecasound-2.8.0/pyecasound/ecacontrol.py, line 154, in initialize if float(version[s+10:s+13])=2.2: ValueError: empty string for float() Could you please take a look? Thanks! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#627192: ecasound: FTBFS on kFreeBSD: 'ESTRPIPE' was not declared in this scope
Package: ecasound Version: 2.8.0-1 Severity: serious Justification: fails to build from source Builds of ecasound on kFreeBSD are failing with errors in audioio_alsa.cpp: audioio_alsa.cpp: In member function 'virtual long int AUDIO_IO_ALSA_PCM::read_samples(void*, long int)': audioio_alsa.cpp:426:52: error: 'ESTRPIPE' was not declared in this scope audioio_alsa.cpp:456:52: error: 'ESTRPIPE' was not declared in this scope audioio_alsa.cpp: In member function 'virtual void AUDIO_IO_ALSA_PCM::write_samples(void*, long int)': audioio_alsa.cpp:532:57: error: 'ESTRPIPE' was not declared in this scope audioio_alsa.cpp:567:57: error: 'ESTRPIPE' was not declared in this scope Could you please take a look? Thanks! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#622079: dvbcut: FTBFS w/GCC 4.5: 'index::index' names the constructor, not the type
Package: dvbcut Version: 0.5.4+svn146-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Builds of dvbcut with GCC 4.5 (the default on most architectures these days) fail with a cascade of errors: src/mpgfile.h: At global scope: src/mpgfile.h:52:3: error: 'index::index' names the constructor, not the type src/mpgfile.h: In member function 'const index::picture mpgfile::operator[](unsigned int) const': src/mpgfile.h:96:12: error: 'idx' was not declared in this scope src/mpgfile.h: In member function 'int mpgfile::lastseqheader(int) const': src/mpgfile.h:100:20: error: 'idx' was not declared in this scope [...] Could you please drop the spurious ::index and check for further errors with the current toolchain? Thanks! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#602453: pd-pmpd: FTBFS - unoconv needs writable $HOME
Vincent Bernat ber...@debian.org writes: listener. Moreover, this is not 100% reliable. I was afraid there might be further complications with unoconv/OO.o, hence my suggestion to split the package (which would, however, require another pass through NEW. :-/) Another possibility might be to use ooo2dbk in conjunction with docbook-utils, dblatex, or the like. Maybe this is is better to keep the documentation in sxw format? Perhaps, though I'd suggest trying to keep the PDF if feasible. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#602453: pd-pmpd: FTBFS - unoconv needs writable $HOME
Felipe Sateler fsate...@debian.org writes: The pdf comes with upstream tarball, we were just regenerating it out of principle. I think we can just install the upstream provided one. That's fair; under the circumstances, I won't object to that approach either, even if it isn't quite as pure. The important facts are that you have the source and can produce an equivalent PDF document with free tools. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#602453: pd-pmpd: FTBFS - unoconv needs writable $HOME
Package: pd-pmpd Version: 0.9-1 Severity: serious Justification: fails to build from source pd-pmpd fires up unoconv to convert its manual from Star Office's native format to PDF, but unoconv evidently needs a writable $HOME for whatever reason: | unoconv -f pdf /build/buildd-pd-pmpd_0.9-1-i386-D5fhxp/pd-pmpd-0.9/manual/pmpd.sxw | stat: cannot read file system information for `/home/buildd': No such file or directory | [Java framework] Error in function createSettingsDocument (elements.cxx). | javaldx failed! | Error: Unable to connect or start own listener. Aborting. | make[1]: *** [override_dh_auto_build] Error 251 To address this, you could either create and use a temporary $HOME or split the docs and examples out into architecture-independent packages (or perhaps a single such). Could you please do so? Thanks! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#571562: cannot populate debian/horgand-data/usr/share in binary-only builds
Package: horgand Version: 1.14-1 Severity: serious Justification: fails to build from source binary-only builds of horgand (most critically, on the build daemons) are running into trouble: mv debian/horgand/usr/share/horgand debian/horgand-data/usr/share/ mv: cannot move `debian/horgand/usr/share/horgand' to `debian/horgand-data/usr/share/': No such file or directory make[1]: *** [override_dh_install] Error 1 I haven't looked at the packaging, but I suspect the problem stems from expecting dh_installdirs to create debian/horgand-data/usr/share, which it does only for full builds; if so, explicitly running mkdir -p debian/horgand-data/usr/share before trying to move anything there should help. Better yet, simply list usr/share/horgand and the like in horgand-data.install rather than horgand.install in the first place! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
