Package: rsyslog
Version: 8.4.2-1
Severity: normal
When booting with systemd and using a separate /usr filesystem,
/dev/xconsole is not automatically created at startup. As it turns out,
there are two .service files for running systemd-tmpfiles at boot:
*
Source: vsearch
Version: 1.0.7+dfsg-1
Severity: serious
Justification: fails to build from source
The i386 build of vsearch compiled without errors, but timed out while
executing the test suite. Given that the test had been reporting
progress, I suspect a hang:
Indexing sequences 99%
Source: vsearch
Version: 1.0.7+dfsg-1
Severity: important
Justification: fails to build from source
The kFreeBSD builds of vsearch failed:
g++ -O3 -DHAVE_BZLIB -msse2 -mtune=core2 -Icityhash -Wall -g -c -o arch.o
arch.cc
arch.cc: In function 'long unsigned int arch_get_memtotal()':
Source: vsearch
Version: 1.0.7+dfsg-1
Severity: important
Justification: fails to build from source
The hurd-i386 build of vsearch failed:
In file included from align.cc:22:0:
vsearch.h:23:24: fatal error: sys/sysctl.h: No such file or directory
#include sys/sysctl.h
Source: vsearch
Version: 1.0.7+dfsg-1
Severity: important
Justification: fails to build from source
Builds of vsearch on non-x86 architectures have been failing due to its
use of the x86-specific compilation flags -msse2 and -mtune=core2.
(Most of the x86 builds have failed as well, due to
Source: ckon
Version: 0.7.1-2
Severity: serious
Justification: fails to build from source
The builds of ckon for i386, hurd-i386, and kfreebsd-i386 (but no
other architectures) all failed:
checking for boostlib = 1.50... yes
checking whether the Boost::System library is available... yes
Source: redis
Version: 2:3.0.0~rc5-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Redis's test suite wound up failing on most platforms, as detailed at
https://buildd.debian.org/status/logs.php?pkg=redisver=2%3A3.0.0~rc5-2suite=sid
For
Source: snappy-java
Version: 1.1.1.6-1
Severity: serious
Justification: fails to build from source
Automatic builds of snappy-java have been failing:
org.apache.maven.project.ProjectBuildingException: POM
'org.sonatype.oss:oss-parent' not found in repository: System is offline.
This looks
changes make sense to me as well, so I've gone ahead with
an upload.
--
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
cp debian/pom.xml .
sed -i 's/%VERSION%/$(DEB_UPSTREAM_VERSION)/g' pom.xml
to
sed -e 's/%VERSION%/$(DEB_UPSTREAM_VERSION)/g' debian/pom.xml pom.xml
in debian/rules.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http
Source: ksmtuned
Version: 3.20150205
Severity: serious
Justification: fails to build from source
Binary-only builds of ksmtuned have been failing:
debian/rules build-arch
dh build-arch --with systemd
dh_testdir -a
dh_auto_configure -a
dh_auto_build -a
dh_auto_test -a
Source: fw4spl
Version: 0.9.2-1
Severity: serious
Justification: fails to build from source
Automated builds of fw4spl have been failing to detect HDF5 fully:
-- Configuring fwAtomsHdf5IO: /«PKGBUILDDIR»/SrcLib/io/fwAtomsHdf5IO
CMake Warning (dev) at CMakeLists.txt:135 (get_target_property):
was i386, so you can try to
reproduce the problem in a 32-bit chroot.
Thanks for looking into this bug (and the other two I reported)!
--
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
--
To UNSUBSCRIBE
configuration, you're unlikely to encounter the relevant
setup elsewhere, even on porter boxes. (If it's instead
architecture-dependent, you may have better luck.)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger
Source: libdevel-callchecker-perl
Version: 0.006-1
Severity: serious
Justification: fails to build from source
The automated build of libdevel-callchecker-perl failed (only) on
i386 due to test suite errors (excerpted from
Source: libjson-rpc-cpp
Version: 0.4.2-3
Severity: serious
Justification: fails to build from source
Builds of libjson-rpc-cpp failed on several platforms with test suite
errors. On armel,
The following tests FAILED:
4 - connector_http (Failed)
6 - integration (Failed)
Source: libjson-rpc-cpp
Version: 0.4.2-3
Severity: serious
Justification: fails to build from source
Builds of libjson-rpc-cpp failed for several architectures with the error
/«PKGBUILDDIR»/src/test/test_integration.cpp:17:35: fatal error:
gen/abstractsubserver.h: No such file or directory
Source: libjson-rpc-cpp
Version: 0.4.2-3
Severity: important
Justification: fails to build from source
The hurd-i386 build of libjson-rpc-cpp failed with the errors
cp: cannot stat 'debian/tmp/usr/share/man/man1': No such file or directory
dh_install: cp -a debian/tmp/usr/share/man/man1
Package: ruby-jquery-ui-rails
Version: 4.2.0-4
Severity: important
rails-assets-jquery-ui.gemspec tries to set spec.files dynamically, as
spec.files = `find ./* -type f | cut -b 3-`.split($/)
However, this find command starts from the overall Ruby process's
current directory, which
for the last five years.
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Source: haskell-hashable
Version: 1.2.3.2-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
The powerpc build of haskell-hashable encountered a test suite failure:
regressions:
hashNearPageBoundary: [Failed]
ERROR: mmap: invalid argument
Source: python-pygit2
Version: 0.21.4-1
Severity: serious
Justification: fails to build from source
Builds of python-pygit2 in minimal environments (as on the
autobuilders) have been failing:
distutils.errors.DistutilsError: Could not find suitable distribution for
Requirement.parse('cffi')
Source: telepathy-qt
Version: 0.9.5+dfsg-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of telepathy-qt against unstable have been impossible, as
telepathy-qt declares a build dependency on libssl1.0.0 (= 1.0.2) but
1.0.2a-1 reached
Package: haskell-platform-doc
Version: 2014.2.0.0.debian1
Severity: important
The latest haskell-platform-doc release has essentially the same
dependencies as haskell-platform-prof; could you please switch its
dependencies back to -doc packages?
Thanks!
--
To UNSUBSCRIBE, email to
Source: subread
Version: 1.4.6-p2+dfsg-1
Severity: serious
Justification: fails to build from source
Builds of subread covering only its main architecture-dependent binary
package (as on the autobuilders, or with debuild -B) have been
failing, even on x86:
tar -cJf
Source: subread
Version: 1.4.6-p2+dfsg-1
Severity: important
Builds of subread on non-x86 architectures have been failing:
gcc: error: unrecognized command line option '-mmmx'
gcc: error: unrecognized command line option '-msse'
gcc: error: unrecognized command line option '-msse2'
gcc:
Package: needrestart
Version: 2.0-2
Followup-For: Bug #781657
I've run into this bug as well. It looks like line 115 of
.../NeedRestart/Kernel/Linux.pm inappropriately removes the first
kernel version component.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http
Package: python3.5
Version: 3.5.0~a4-3
Severity: grave
Justification: renders package unusable
Configuring python3.5 consistently fails with a strange error:
Setting up python3.5 (3.5.0~a4-3) ...
Sorry: IndentationError: too many levels of indentation (IN.py, line 806)
dpkg: error
Source: libuv1
Version: 1.4.2-1
Severity: serious
Justification: fails to build from source
The automated builds of libuv1 all failed with test suite errors.
For some reason, pipe_set_non_blocking failed everywhere:
`pipe_set_non_blocking` failed: exit code 6
Output from process
Package: golang-mode
Version: 3:1.3.0-1
Severity: normal
Byte-compilation of golang-mode for xemacs21 fails:
While compiling toplevel forms in file
/usr/share/xemacs21/site-lisp/golang-mode/go-mode.el:
!! File error ((Cannot open load file find-file))
Error occurred processing
Source: pysph
Version: 0~20150606.gitfa26de9-1
Severity: serious
Justification: fails to build from source
Thanks for taking care of the build errors I previously reported; I'm
pleased to confirm that neither is still a problem. Nevertheless,
automatic builds of pysph are still failing because
Source: pysph
Version: 0~20141130.git9132872-1
Severity: serious
Justification: fails to build from source
Builds of pysph in environments (notably, on the autobuilders) lacking
writable home directories have been failing when trying to run tests
(assuming they get past #787573):
File
Source: pysph
Version: 0~20141130.git9132872-1
Severity: serious
Justification: fails to build from source
Builds of pysph against Cython 0.22 have been failing, as detailed
below. (Cython itself FTBFS on several architectures per
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787234.) Could
Source: memtailor
Version: 1.0~git20130809-1
Severity: important
Builds of memtailor for 32-bit architectures like i386 have been
failing because some methods have slightly different formal types, and
thus slightly different mangled names, on 32- and 64-bit
architectures. Could you please
know.
At any rate, thanks for the quick response!
--
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe
Source: murasaki
Version: 1.68.6-2
Severity: important
Thanks for promptly fixing binary-only builds of murasaki in general.
However, I see that the kFreeBSD builds are still failing. The
problem appears to be that globaltypes.h defines WORDSIZE only for
Linux, Mac OS X, and normal FreeBSD
Source: volk
Version: 1.0-3
Severity: important
Builds of volk for armel and armhf have been failing:
/usr/bin/c++ -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wall -fvisibility=hidden
-Wl,-z,relro CMakeFiles/test_all.dir/testqa.cc.o
Source: ignition-math2
Version: 2.1.1+dfsg1-1
Severity: important
Builds of ignition-math2 wound up failing with test suite errors on a
few platforms:
* On i386 with any kernel (Linux, FreeBSD, or the Hurd),
UNIT_Line2_TEST fails:
[ RUN ] Line2Test.CollinearPoint
Source: murasaki
Version: 1.68.6-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of murasaki covering only its architecture-dependent binary
packages (as on the autobuilders) have been failing:
for pscript in
Source: seqprep
Version: 1.1-2
Severity: important
Builds of seqprep for i386 with any kernel (Linux, kFreeBSD, or the
Hurd) have been failing:
[ `cat Test/info/pe_*.txt | md5sum | cut -b -10` = 8bc8e0787e ]
make[1]: *** [override_dh_auto_test] Error 1
debian/rules:19: recipe for target
Source: pyosmium
Version: 2.1.0-1
Severity: important
32-bit builds of pyosmium have been failing:
I: pybuild base:170: cd test python2.7 run_tests.py
F..
==
FAIL: test_broken_timestamp
for $samtools mpileup -x -F 0.60 -u -f
mpileup.ref.fa indels.cram|$filter|awk '/INDEL/'
See FAIL-59.out.2 vs expected/59.out
Could you please look into them as well?
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
until the fix
reaches Debian.
--
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Source: kwidgetsaddons
Version: 5.11.0-1
Severity: important
Builds of kwidgetsaddons for arm64, armel, and armhf (but no other
architectures) all failed. The arm64 build simply reports
7/10 Test #10: kwidgetsaddons-kcolumnresizertest ...***Failed0.48 sec
* Start testing of
, and
s390x), as detailed at
https://buildd.debian.org/status/logs.php?pkg=nfstracever=0.4.0-2
Could you please take another look?
(The armel failure stems from an unrelated toolchain issue,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 .)
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu
Source: emoslib
Version: 2:4.0.3+dfsg.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of emoslib for most Linux architectures have been failing
because it always specifies the non-portable flag -mcmodel=medium.
Judging by the ppc64el
Source: emoslib
Version: 2:4.0.3+dfsg1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
The ppc64el build of emoslib failed with link errors:
/usr/bin/gfortran -fPIC -ffixed-line-length-none -fcray-pointer
-fno-second-underscore
Source: emoslib
Version: 2:4.0.3+dfsg.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
The Hurd build of emoslib failed:
-- Detecting C compile features
CMake Error at cmake/ecbuild_check_os.cmake:336 (message):
ecBuild is untested for
Package: dpkg-dev
Version: 1.18.1
Severity: important
When unpacking a .debian tarball, dpkg-source explicitly excludes any
files that were already in the corresponding .orig tarball, which in
some cases can yield excessively long command lines. In particular,
this approach makes it impossible
Package: libdbustest1
Version: 15.04.0~bzr87+repack1-1
Severity: important
libdbustest1 specifies
Breaks: dbus-test-runner ( 15.04.0)
Replaces: dbus-test-runner ( 15.04.0)
which is a problem because the current dbus-test-runner package has
version 15.04.0~bzr87+repack1-1 and depends on
Source: pygccjit
Version: 0.4-2
Severity: important
Justification: fails to build from source
Thanks for promptly fixing pygccjit's build dependencies. 64-bit
builds now succeed, but 32-bit builds still fail, just further along:
Source: pygccjit
Version: 0.4-1
Severity: serious
Justification: fails to build from source
Builds of pygccjit in minimal environments geared for building only
its architecture-dependent binary packages (as on the autobuilders)
have been failing:
dh clean --with python2,python3,sphinxdoc
Source: rasterio
Version: 0.15.1-1
Severity: serious
Justification: fails to build from source
Builds of rasterio with cython 0.22.x have been failing because cython
now checks that signatures' and definitions' exception specifications agree:
Error compiling Cython file:
Source: gyoto
Version: 1.0.1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of gyoto for 32-bit architectures such as i386 have been failing:
In file included from Photon.C:26:0:
../include/GyotoWorldline.h:65:37: error: no matches
Source: parafly
Version: 0.0.2013.01.21-1
Severity: important
32-bit builds of parafly have all failed because its build system
always specifies -m64. Some platforms don't support this flag at all,
and others effectively support it only with g++-multilib installed.
Parafly may well benefit from
notfixed 790403 0.10.2-1
found 790403 0.10.2-1
thanks
* Add BD on xvfb, xauth, and use xvfb-run on dh_auto_test so qt tests
run on systems without an X server (Closes: #790403)
Thanks for giving this approach a shot, but it appears to have been
insufficient. :-/
--
Aaron M. Ucko
Source: pandas
Version: 0.16.2+git65-g054821d-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of pandas have been failing with test suite errors of the form
ERROR: test_creating_and_reading_multiple_sheets
Source: pandas
Version: 0.16.2+git65-g054821d-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
The armhf and sparc builds of pandas both failed with a bus error in
test_append_frame_column_oriented:
test_append_frame_column_oriented
Source: elixir-lang
Version: 1.1.0~0.20150516-1
Severity: serious
Justification: fails to build from source
Automated builds of elixir-lang have all been failing with a pair of
test suite errors:
== elixir (exunit)
..
by default to avoid totally breaking ABI compatibility, as
described at http://www.fltk.org/cmp.php#FLTK_ABI_VERSION. I would then
of course rename the runtime library packages accordingly, calling for a
trip through NEW.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http
things alive? ;)
I've pushed a rough cut of 1.3.3 packaging to my usual Alioth
repository. I haven't tested it beyond confirming that it builds.
--
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
a look later this week.
Thanks for letting me know.
--
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Thanks for pointing it out, and sorry you've been finding my packaging
approach hard to deal with -- for my part, I've always found patch
systems unnecessarily cumbersome, especially when sources are already
under conventional version control.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko
Source: nfstrace
Version: 0.4.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Automated builds of nfstrace have been failing with test suite
errors. Test #60 fails everywhere:
60/63 Test #60: unit_test_json_analyzer
Source: influxdb
Version: 0.9.2+dfsg1-2
Severity: serious
Justification: fails to build from source
Builds of influxdb on armhf and i386 (the only architectures other
than amd64 on which its build dependencies are all available)
encountered an identical combination of test failures, as detailed
Source: graywolf
Version: 0.1.2-1
Followup-For: Bug #795508
This error appears to stem from an incompatibility with GCC 5, in
whose default language level (C99) restrict is a keyword.
.)
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
.)
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
Source: grpc
Version: 0.10.0-1
Severity: important
Justification: fails to build from source
Builds of grpc for 32-bit architectures (i386 and powerpc so far) have
been failing:
[C] Compiling test/core/iomgr/tcp_server_posix_test.c
In file included from
Source: netty-tcnative
Version: 1.1.33.Fork4-1
Severity: serious
Justification: fails to build from source
Builds of netty-tcnative in minimal environments geared for covering
only its architecture-dependent binary package have been failing:
[ERROR] BUILD ERROR
[INFO]
Source: ori
Version: 0.8.1+ds1-1
Severity: important
Justification: fails to build from source
Builds of ori on kFreeBSD and the Hurd have been failing:
public/oriutil/rwlock.h:33:2: error: #error UNSUPPORTED OS
The problem appears to be that ori has a whitelist of supported
Unix-like
Source: botan1.10
Version: 1.10.8-2
Severity: serious
Justification: fails to build from source
Builds of botan1.10 for architectures other than amd64 and
kfreebsd-amd64 have been failing with symbol mismatches, as detailed at
https://buildd.debian.org/status/logs.php?pkg=botan1.10ver=1.10.10-2
Package: wnpp
Severity: normal
I plan to request removal of bitpim unless somebody cares enough about
the package to take it over within the next few weeks. (If and when
it is removed, resurrection will be possible, just require going
through NEW again.)
The package description is
BitPim
Source: urweb
Version: 20150214+dfsg-1
Severity: serious
Justification: fails to build from source
Builds of urweb in minimal environments geared for building its
architecture-dependent binary packages (as on the autobuilders) have
been failing:
make[2]: Leaving directory
Source: bitcoin
Version: 0.10.1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Automated builds of bitcoin have been failing:
../build-aux/test-driver: line 107: 20324 Aborted $@
$log_file 21
FAIL: qt/test/test_bitcoin-qt
Source: rasterio
Version: 0.24.0-1
Severity: important
Thanks for addressing rasterio's Cython 0.22 incompatibility. The new
version builds on most architectures, but fails with test suite errors
on i386 and kfreebsd-i386:
=== FAILURES
://www.ncbi.nlm.nih.gov/viewvc/v1/trunk/c%2B%2B/include/util/bitset/bmconst.h?view=log
http://www.ncbi.nlm.nih.gov/viewvc/v1/trunk/c%2B%2B/include/util/bitset/bmconst.h?r1=45514r2=67997view=patch
Olivier, would you like to incorporate it, or should I?
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko
Source: apophenia
Version: 0.999b+ds3-2
Severity: serious
Justification: fails to build from source
Builds of apophenia fail for several architectures with test suite
errors, as follows:
* distribution_tests fails on *i386 and ppc64el.
* ../eg/test_updating fails on arm64, (traditional) powerpc,
Source: sfcgal
Version: 1.1.0-1
Severity: serious
Justification: fails to build from source
Builds of sfcgal for architectures other than amd64 have all failed
with symbol mismatches, as detailed at
https://buildd.debian.org/status/logs.php?pkg=sfcgalver=1.1.0-1
(It's possible that
logins are restricted
to their actual maintainers. Rather, my test builds were on
harris.debian.org (armhf) and eder.debian.org (mipsel).
--
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
Stefan Sobernig stefan.sober...@wu.ac.at writes:
I would still appreciate it if you could test on abel.
I did just now, and had a successful build there too. I wonder what
went wrong originally.
Anyway, thanks again!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http
myself, just keep an eye out for new binary packages that appear on
amd64 but not i386 or vice versa.
--
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
found 793998 0.999e+ds-2
notfixed 793998 0.999e+ds-2
thanks
These failures are still occurring, and may well indicate real problems,
in which case ignoring them by disabling the tests would have been
inappropriate anyway. Could you please take another look?
Thanks!
--
Aaron M. Ucko, KB1CJC
nicely, they might be able to
help you out. I tried building the package on a physical porterbox of
each architecture, but wasn't able to reproduce the error on either, so
I'm not sure why the automatic builds failed.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http
Source: libcec-platform
Version: 1.0.10+dfsg1-1
Severity: important
Justification: fails to build from source
Builds of libcec-platform for architectures with CPUs other than amd64
and s390x all failed with symbol mismatches:
--
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
As such, I'm contemplating having libfltk1.3-dev either override or
simply divert FindFLTK.cmake for the time being.
--
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
--
To UNSUBSCRIBE, email to debian-bugs-dist
I've worked around both of these problems on my side for now for the
sake of the GCC 5 transition, but may want to revisit them once that's
settled down.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger
Package: libdivsufsort-dev
Version: 2.0.1-1
Severity: serious
Justification: Policy 8.4
libdivsufsort-dev should depend on libdivsufsort3 to ensure that
libdivsufsort.so won't dangle.
$ ls -l /usr/lib/libdivsufsort.*
lrwxrwxrwx 1 root root 22 Jul 28 10:59 /usr/lib/libdivsufsort.so -
packages such as fgrun can work around the issue by explicitly
invoking
cmake ... -DFLTK_FLUID_EXECUTABLE=/usr/bin/fluid ...
--
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
--
To UNSUBSCRIBE
Source: exiv2
Version: 0.25-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of exiv2 for 32-bit architectures such as i386 have been failing
because they wind up with a somewhat different set of (mangled) symbol
names than 64-bit builds
time at the moment.
Thanks for checking!
--
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe
Source: libterralib
Version: 4.3.0+dfsg.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of libterralib for kFreeBSD and the Hurd now fail:
../../../src/libspl/include/spl_platform.h:84:3: error: #error ERROR:
Operating system is
to running makeblastdb:
sed -e '/^/y,|,!,; s/^\([a-z]\)/lcl|\1' foo.aa foo-disguised.aa
Of course, you'd then likely want a compensatory transformation on the
output side.
Thanks for all your help diagnosing the problem!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org
Source: dogecoin
Version: 1.8.0-1
Severity: important
Justification: fails to build from source
The arm64 and mipsel builds of dogecoin both failed:
In file included from ./port/port_posix.h:50:0,
from ./port/port.h:14,
from helpers/memenv/memenv.cc:9:
Source: kmc
Version: 2.0+dfsg-1
Severity: important
Justification: fails to build from source
Builds of kmc for architectures other than amd64 fail due to
inappropriate makefile settings.
First off, as reported in #793835, the makefile explicitly specifies
-m64. On some architectures, this
Source: msitools
Version: 0.94-1
Severity: important
Justification: fails to build from source
Builds of msitools for 32-bit architectures such as i386 have been failing:
15: Update _SummaryInformation tableFAILED (testsuite.at:216)
Could you please take a look?
Thanks!
--
Source: nsf
Version: 2.0.0-1
Severity: serious
Justification: fails to build from source
Builds of nsf on Linux architectures failed with test suite errors, of
two types. (There was also a kFreeBSD failure, which I'll report
separately.)
On armhf and mipsel, the linearization test segfaults
Source: dogecoin
Version: 1.8.0-1
Severity: serious
Justification: fails to build from source
Automated builds of dogecoin that get as far as the test suite have
been failing:
../../../src/build-aux/test-driver: line 107: 20919 Aborted
$@ $log_file 21
FAIL: test_dogecoin-qt
Source: dogecoin
Version: 1.8.0-1
Severity: important
Justification: fails to build from source
Builds of dogecoin fail on big-endian architectures, which it
evidently doesn't support:
checking whether byte ordering is bigendian... yes
configure: error: Big Endian not supported
I suppose
1 - 100 of 3051 matches
Mail list logo
