e conditionalize the debian/rules commands that work with
giac-doc appropriately, for instance by renaming override_dh_fixperms
to override_dh_fixperms-indep.
Thanks!
FTR, even though giac is new to Debian, I'm classifying this bug as a
regression because it would affect potential binNMUs.
-
ease architectures alpha, hppa, m68k, powerpc,
ppc64, sparc64, and x32.
Could you please take a look?
Thanks!
NB: some of the above output may be from hevea, which ran in parallel
with icas.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff
as detailed at
https://buildd.debian.org/status/fetch.php?pkg=giac&arch=hurd-i386&ver=1.2.3.25%2Bdfsg1-1&stamp=1486947346&raw=0
(affecting every top-level test, and what appears to be nearly all
individual cases).
Could you please take a look?
Thanks!
--
Aaron M. Ucko
s/fetch.php?pkg=giac&arch=kfreebsd-i386&ver=1.2.3.25%2Bdfsg1-1&stamp=1486951903&raw=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
--
debian-s
ips64el and ppc64el builds encountered worse mismatches, roughly
4.4% and 7.7% respectively.
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
--
debi
8-1&stamp=1492853191&raw=0
The builds for the 32-bit non-release architectures m68k and
powerpcspe both nominally succeeded, but AFAICT only because they
skipped the test suite altogether for some reason.
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu,
e altogether 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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth
0.25 required)
Please version the build dependency on cython accordingly.
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
--
debian-science-maintainers mailing list
debian-science
'matplotlib._path'
I see that hurd-i386 still just has matplotlib 1.5.x, whereas the
other architectures have 2.x; please version the build dependencies on
python(3)-matplotlib accordingly.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~a
Source: python-escript
Version: 4.2.0.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of python-escript in minimal environments (notably, on the
autobuilders) have been failing:
RuntimeError: netcdf.h not found under /usr:
File "/«
Source: python-escript
Version: 4.2.0.1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Thanks for fixing python-escript's build dependencies quickly.
Architecture-specific builds now look good for the most part (aside
from portability issues to s
ainer-supplied arch-all packages (as occurred here) call
for a higher severity in this scenario.
> (BTW: I have just added this bug to the collection :-)
Great, 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
Source: hfst
Version: 3.10.0~r2798-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of hfst for many architectures failed because the hfst-twolc
test either hit an inactivity timeout (which is generous enough that
it typically indicates a ha
Source: hfst
Version: 3.10.0~r2798-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Thanks for taking care of the twolc errors I reported in #826659. The
twolc test now succeeds on little-endian systems, and no longer hangs
anywhere, but still fai
Source: mpi-testsuite
Version: 3.2+dfsg-1
Severity: important
Justification: fails to build from source
Builds of mpi-testsuite for most architectures failed with test suite
timeouts, as detailed at
https://buildd.debian.org/status/logs.php?pkg=mpi-testsuite&ver=3.2%2Bdfsg-1
The last test started
Source: mpi-testsuite
Version: 3.2+dfsg-1
Severity: important
Justification: fails to build from source
Builds of mpi-testsuite on kFreeBSD and the Hurd have been failing:
config.status: executing default-4 commands
for i in `find . -name "testlist" | grep -v ^..build`;\
do
Source: evolver
Version: 2.70+ds-1
Severity: important
Justification: fails to build from source
The i386 build of evolver failed:
../../../src/tmain.c: In function 'task_caller':
../../../src/extern.h:2383:38: error: subscripted value is neither array nor
pointer nor vector
asm("movl %
Source: evolver
Version: 2.70+ds-1
Severity: important
Justification: fails to build from source
Builds of evolver for kFreeBSD and the Hurd failed:
../../../src/painter.c: In function 'painter_start':
../../../src/painter.c:441:20: error: storage size of 's' isn't known
{ struct sysinfo
Source: fcl
Version: 0.5.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
The mips build of fcl failed with a timeout in test_fcl_octomap,
likely due to a hang. Could you please take a look?
Thanks!
--
debian-science-maintainers mailing list
Source: form
Version: 4.1-1
Severity: important
Justification: fails to build from source
form's tests failed on several architectures, as detailed at
https://buildd.debian.org/status/logs.php?pkg=form&ver=4.1-1 .
Could you please take a look?
Thanks!
--
debian-science-maintainers mailing list
Source: ros-geometry-experimental
Version: 0.5.13-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of ros-geometry-experimental against libgeometry-msgs-dev
1.12.4-3 have been failing:
Could not find messages which
'/«PKGBUILDDIR»/tf2_m
Kokkos_Atomic_Compare_Exchange_Strong.hpp:207:3:
error: invalid use of incomplete type 'struct Kokkos::Impl::enable_if'
Could you please take another look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.ed
Source: trilinos
Version: 12.6.4-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Thanks for looking into #835406! trilinos now successfully builds on
i386 and x32, and the builds for other 32-bit architectures don't fail
as quickly as they used t
Source: opengm
Version: 2.3.6+20160131-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Thanks for taking care of #806379!
opengm is now in good shape on 64-bit architectures (apart from one
test failure on sparc64, which isn't a release architect
Source: opengm
Version: 2.3.6+20160901-1
Severity: important
Justification: fails to build from source
opengm now compiles on powerpc (thanks!), but hits a test suite error:
23/49 Test #24: test-io-hdf5 .***Exception: Other 0.11
sec
terminate called after throwing an ins
can work
> together on a solution.
Great; thanks for all your work here.
> PS: If you are happy with the outcome of #815725, please close it.
Done earlier today. In retrospect, that really should have been two
separate reports.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debi
found 766303 3.0.0+dfsg-2
thanks
"Aaron M. Ucko" writes:
> ls: cannot access
> debian/gazebo3-common/usr/share/gazebo-*/media/gui/fonts/DejaVuSans.ttf: No
> such file or directory
Thanks for looking into this report. Builds now get past the original
error only 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
co
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: 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 "/«PKGB
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 th
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 account
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
/«BUILDDIR»/ignit
Source: sfepy
Version: 2015.1-1
Severity: important
Builds of sfepy failed everywhere but the Hurd (whose autobuilder
evidently uses a slightly different setup):
Making output directory...
Running Sphinx v1.2.3
WARNING: extension 'ipython_console_highlighting' has no setup() function; is
i
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,
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
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.ali
hanks!
--
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/d
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mai
/fetch.php?pkg=sagemath&arch=arm64&ver=8.0-7&stamp=1505101830&raw=0
2 items had failures:
10 of 26 in sage.combinat.partitions.number_of_partitions
1 of 3 in sage.combinat.partitions.run_tests
[35 tests, 11 failures, 8.05 s]
Could you please take a look?
Thanks!
-
it build depends on Qt4 bindings only via fabio:
File
"/<>/silx-0.5.0+dfsg/.pybuild/pythonX.Y-dbg_3.6/build/silx/gui/qt/_qt.py",
line 110, in
from PyQt4.QtCore import * # noqa
ModuleNotFoundError: No module named 'PyQt4.QtCore'
Could you please take a l
) timeout, presumably due to
hanging or spinning. I don't have details beyond
https://buildd.debian.org/status/fetch.php?pkg=plplot&arch=mipsel&ver=5.13.0%2Bdfsg-1&stamp=1506091509&raw=0
but perhaps you can reproduce this misbehavior on a porter box. Could
you please take a look?
6-gnu/devel/lib/python2.7/dist-packages/roscpp/msg'
ERROR: Unable to generate messages for package 'roscpp': while processing
'/<>/ros-ros-comm-1.13.2+ds1/clients/roscpp/msg/Logger.msg': [Errno
1073741841] File exists:
'/<>/ros-ros-comm-1.13.2+ds1/ob
/ros-ros-comm-1.13.2+ds1/clients/roscpp/src/libros/transport/transport_tcp.cpp:196:36:
error: 'TCP_KEEPCNT' was not declared in this scope
I suspect builds for hurd-i386 will fail in the same way if and when
somebody helps them past #876745.
Could you please take a look?
Thanks!
--
e explicitly
resetting them on all platforms.
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
--
debian-science-maintainers mailing list
debian-science-maint
his interface is generally deprecated, so my
recommendation would be to steer clear of it on any Linux
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
--
on amd64 and/or i386.
--
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi
uple of
other non-release architectures, so only old, broken versions are
available there. Please version the build dependency on libtbb-dev to
(>= 2017~) to avoid bothering to try building against these old
versions.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
htt
Mattia Rizzolo writes:
> Well, it didn't reach the point it failed before…
Good point; I'd noticed that the error had changed, but didn't properly
register why. :-) Looks good now, thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mi
n of fully successful tests elided]
=== TESTING SUMMARY =
The one exception was sparc64, which encountered many more errors;
I'll report a separate bug for that architecture.
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB
ion/test/regress/regress0/unconstrained/test-suite.log
5 TOTAL, 2 PASS, 3 FAIL
/.../production/test/system/test-suite.log
4 TOTAL, 4 PASSin unit
=== TESTING SUMMARY =========
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at
nding binary
package here and on hppa, though the Architecture: field alas lacks
support for negative entries. Another alternative could be to version
the default-jdk build dependency; if you go that route, please bear in
mind that it currently has an epoch of 2, so you'd want to specif
: testImageType.cpp:428: void testImageType(unsigned int, unsigned
int): Assertion `bResult' failed.
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
--
d
arrange to predefine any
applicable HAVE_* macros?
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lis
compilation and upstream installation errors
for each of them, and don't actually fail until debian/rules tries to
rename gmap.1 to scotch_gmap.1 (presumably to avoid a file conflict).
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.ed
e any platforms or get
formal dependencies on libatomic on the platforms that don't need it
here.
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
--
debian
igh in with recommendations, but see that cycleclock.h does also
supply a fallback implementation whose scope you can broaden as
needed.
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...@m
AULT)
Errors while running CTest
On both architectures, the failed tests are reporting 0 ns wall and
cpu time, making for infinite rates that rightly don't match the
expected patterns.
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian
R: clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...) failed
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.a
these architectures!), but perhaps you can
reproduce the problem on a porter box.
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
--
debian-science-maint
:
/<>/normaliz-3.4.1+ds/_build/../test/Makefile.classic:52: recipe
for target 'test-v/medium.diff' failed
As with #881869, I don't know what the diff turned out to read, but
perhaps you can reproduce the problem on a porter box.
Could you please take a look?
Thanks!
--
led)
639 - ML_MLP_Maxwell_MPI_4 (Failed)
640 - ML_MLP_NonSym_MPI_4 (Failed)
648 - Komplex_simple_MPI_4 (Failed)
Errors while running CTest
--
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
d 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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
t file
read inline 4
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.
c
The following tests FAILED:
6 - python.tools (Failed)
Errors while running CTest
Makefile:122: recipe for target 'test' failed
--
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
--
de
s GLES rather than traditional OpenGL here.
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
--
debian-science-maintainers mailing list
debian-scienc
org/status/fetch.php?pkg=ovito&arch=powerpc&ver=2.9.0%2Bdfsg1-5&stamp=1511222775&raw=0
https://buildd.debian.org/status/fetch.php?pkg=ovito&arch=ppc64&ver=2.9.0%2Bdfsg1-5&stamp=1511219276&raw=0
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at al
ted alternative: 'log1p'
/usr/lib/R/etc/Makeconf:168: recipe for target 'Polynomial.o' failed
make[1]: *** [Polynomial.o] Error 1
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
--
Ran 20 tests in 0.030s
FAILED (errors=1)
[...]
90% tests passed, 3 tests failed out of 31
Total Test time (real) = 3.69 sec
The following tests FAILED:
1 - c.segy (Failed)
3 - python.segy (Failed)
4
"use \"./ROOT.sml\";" | ../../poly -q -error-exit
poly: memmgr.cpp:957: void MemMgr::AddTreeRange(SpaceTree**, MemSpace*,
uintptr_t, uintptr_t): Assertion `t->tree[r] == 0' failed.
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.e
you please take a look?
Thanks!
[1]
https://buildd.debian.org/status/fetch.php?pkg=mumps&arch=m68k&ver=5.1.2-2&stamp=1513807447&raw=0
[2] https://packages.debian.org/sid/m68k/libmpich-dev/filelist
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.e
ly related.
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http:
errors I just reported as #840454:
FAIL: test-pluq-check
=
terminate called after throwing an instance of 'FailureTrsmCheck'
FAIL test-pluq-check (exit status: 134)
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.ed
y on fflas-ffpack to ensure you get
a version that ships fflas-ffpack.pc. (Alternatively, if the 1.6.0
API is sufficient for your purposes, you could explicitly set
FFLAS_FFPACK_{CFLAGS,LIBS}.)
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~a
[...]
../build-aux/test-driver: line 107: 16135 Illegal instruction "$@" >
$log_file 2>&1
FAIL: test-charpoly
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/c
ct.
I would suggest adding explicit long and unsigned long variants on
these architectures (but not 64-bit architectures, on which they'll
duplicate the existing [u]int64_t variants.)
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at
yields OpenMPI; although that's thankfully valid for all release
architectures nowadays, the non-release architectures m68k and sh4 both
still use MPICH.
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/ |
rved hash values still appear to vary only by word size, but
are different from what the tests expect. 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
--
de
(any matches for)
"usr/lib/glade/modules/libgladedatabox.*" (tried in "." and "debian/tmp")
dh_install: libgtkdatabox-0.9.3-0-glade missing files:
usr/lib/glade/modules/libgladedatabox.*
dh_install: missing files, aborting
Could you please take a look?
Thanks!
that half of a Trilinos package on
> 32-bit architectures would not be useful.
Fair enough, particularly given that the only reverse dependency I see
is deal.ii, which relies on several indirectly affected packages.
Thanks for looking into the problem!
--
Aaron M. Ucko, KB1CJC (amu at alum
y: array([-12727770.5987, 12727770.5987])
--
Ran 70 tests in 0.066s
FAILED (SKIP=1, failures=1)
--
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
t.
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailma
-3&stamp=1482425583
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.deb
s-is.
Thanks for clarifying. You might want to consider conditionalizing the
docbuild anyway to save build time and disk space, since crashing at
startup would presumably also break the test suite.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://
ace in some underlying
library; I particularly suspect proj4.
--
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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debi
+= -ffloat-store
+endif
+
# `nostrip' handled by dh_strip...
CFLAGS += -I$(JAVA_HOME)/include/linux
--
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
--
debian-science-maintainers mailing lis
found 789826 2.2.2+dfsg1-1
notfixed 789826 2.2.2+dfsg1-1
thanks
"Aaron M. Ucko" writes:
> Builds of ignition-math2 wound up failing with test suite errors on a
> few platforms:
2.2.2+dfsg1-1 indeed fixed the UNIT_Line2_TEST errors in *i386, but
still encountered test suite err
Source: woo
Version: 1.0-1
Severity: important
Builds of woo for non-x86 architectures all failed due to trying to
invoke the compiler with the x86-specific flag -march=core2. This
flag isn't appropriate even on x86, because it limits the portability
of the resulting binaries, so please leave it
Source: woo
Version: 1.0-1
Severity: important
Builds of woo on kFreeBSD failed because it tries to use the "gold"
linker, which is unavailable there:
c++ -pthread -shared ... -o
/«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build/woo/_cxxInternal.so -fuse-ld=gold
-Wl,--strip-all
collect2: fatal er
notfixed 793998 0.999b+ds3-3
found 793998 0.999b+ds3-3
thanks
"Aaron M. Ucko" writes:
> * distribution_tests fails on *i386 and ppc64el.
> * ../eg/test_updating fails on arm64, (traditional) powerpc, and s390x.
These two tests are better now, thanks!
> * s390x has one other
notfixed 797092 1.0-2
found 797092 1.0-2
thanks
"Aaron M. Ucko" writes:
> Builds of woo for non-x86 architectures all failed due to trying to
> invoke the compiler with the x86-specific flag -march=core2. This
> flag isn't appropriate even on x86, because it limits
Source: healpy
Version: 1.8.1-1
Severity: important
Justification: fails to build from source
Builds of healpy for ppc64 and ppc64el have been failing because
python-matplotlab tries to use the tkagg backend, which requires the
python-tk package. A typical backtrace is
self =
def tes
Source: slepc
Version: 3.6.1.dfsg1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Builds of slepc in minimal environments (such as on the autobuilders)
have been failing with errors of the form
Checking environment... done
Checking PETSc ins
Source: opengm
Version: 2.3.6-1
Severity: important
Justification: fails to build from source
Those builds of opengm that got as far as running the test suite
nearly all encountered at least one failure. Some builds failed
earlier, due to errors I'll report separately. The only architecture
on w
Source: opengm
Version: 2.3.6-1
Severity: important
Justification: fails to build from source
Builds of opengm for kFreeBSD failed:
/«PKGBUILDDIR»/include/opengm/utilities/meminfo.hxx: In static member
function 'static double sys::MemoryInfo::usedSystemMem()':
/«PKGBUILDDIR»/include/opengm/u
Source: opengm
Version: 2.3.6-1
Severity: serious
Justification: fails to build from source
The x32 build of opengm failed because it (supposedly) couldn't find
HDF5:
-- build with HDF5 support
-- Checking HDF5 version (at least 1.8): ok
CMake Error at
/usr/share/cmake-3.3/Modules/FindPack
Source: libosmocore
Version: 0.9.0-1
Severity: important
Justification: fails to build from source
Builds of libosmocore for the three big-endian architectures attempted
so far (powerpc, s390x, and sparc64) all failed with test suite errors
of the form
7. testsuite.at:45: testing smscb ...
./
Source: ros-pluginlib
Version: 1.10.1-1
Severity: important
Justification: fails to build from source
Builds of ros-pluginlib for architectures other than amd64 have been
failing due to a hardcoded architecture tuple:
-- Build files have been written to: /«PKGBUILDDIR»/obj-i586-linux-gnu
echo
Source: linop
Version: 0.8-1
Severity: serious
Justification: fails to build from source
Builds of linop covering only its architecture-dependent binary
packages and skipping its architecture-independent -doc package (as on
the autobuilders) have been faiing:
dh_sphinxdoc -a -O--buildsystem=
found 738735 0.8.2-1
thanks
It looks like you never committed an actual fix; could you please do so?
You can test the change by running gbp buildpackage -B.
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
1 - 100 of 137 matches
Mail list logo
