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
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
: 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
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/
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
"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
/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
'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 ma
"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
uggestion 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-m
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
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
!
--
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
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
esn'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
_
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
e 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
lders 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-mult
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
. 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
ngs, 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/fin
/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
ined
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-multim
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
lows 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, u
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
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
, 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
.
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
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
<
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
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:
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:
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
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
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
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
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
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
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
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'
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
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
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
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
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)':
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:
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
. 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
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
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
51 matches
Mail list logo
