(>= 1.4-3~)
Is mig (available only on *i386) necessary to have when building only
documentation? If not, please split it out into a separate
Build-Depends-Arch field, along with anything else needed only when
building the main architecture-dependent binary package.
Thanks!
--
Aaron M. U
patch slightly to add back partial coverage of the test directory for
the sake of fltk1.1-games, but it's still a great starting point. Don't
worry, the projects I'll be reenabling should still be cross-buildable,
since none relies on trying to run (cross-built) fluid.
--
iUnitTests. The GpuUtilsUnitTests
regression remains, though.
--
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
ou think that's likely to
make a difference; I just didn't yet have an x32 chroot there at all,
and would need to reboot it to enable the necessary kernel parameter
(syscall.x32=y).
I hope that information helps!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://ww
Abdelhakim Qbaich writes:
> Do you know if there is a way to obtain the test1.out?
AFAIK, the only way is to reproduce the error. Copying the porters for
assistance, since I see no general-access porter box and don't have
access to the autobuilders or to private porter boxes.
--
Total Test time (real) = 62.48 sec
The following tests FAILED:
2 - TestUtilsMpiUnitTests (Timeout)
13 - MdrunUtilityMpiUnitTests (Timeout)
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.e
: recipe for target 'test1' failed
make[2]: *** [test1] Error 139
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
other standard header first; the
ones you have should work nicely.)
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
Control: notfixed -1 2.17.0-2
Control: found -1 2.17.0-2
"Aaron M. Ucko" writes:
> /usr/include/c++/7/bits/atomic_base.h:396: undefined reference to
> `__atomic_load_8'
These errors are still present in 2.17.0-2. Could you please take
another look?
Thanks!
--
Aaron
...]
>
> Is this a known ppc64 peculiarity or a binutils bug?
Good question. Porters?
--
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
Nicholas D Steeves writes:
> WuBingzheng says he will tag a new release soon, so I'll save this fix
> for then.
Sounds good, no need to reupload just for this formal fix.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~
Nicholas D Steeves writes:
> Would you agree that because "builds unsupported
> architectures fail almost immediately" it is best to only explicitly
> disable architectures for which there is not planned future support?
Sure, that's fair. Thanks for checking!
--
Aaron
reasonable
to leave it as is either.
--
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
ually...
Ah, ok. Sounds like whatever setup this test uses to check symbol
availability managed to misfire, then.
--
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
t support x32, but I suppose you could see if
building with -fsanitize=address catches anything. (Also, I'm not sure
autobuilders retain any details they don't publish anyway.)
--
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
option 33:
Operation not permitted
[...]
[knet]: [ERROR] transport: Failed to set socket buffer via force option 33:
Operation not permittFAIL api_knet_send_crypto_test (exit status: 139)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/
ror 1
The build otherwise went well; in particular, the functionality tests
all successfully built and ran.
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
obuilders are
out of commission) because netinet/sctp.h does exist there.
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
endencies are fairly minimal.)
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
nly broke.
Meanwhile, what's your take on
https://buildd.debian.org/status/fetch.php?pkg=tinyssh&arch=m68k&ver=20180101-1&stamp=1515027549&raw=0?
More qemu lossage or an actual tinyssh bug?
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~a
h.php?pkg=ros-bond-core&arch=m68k&ver=1.8.1-2&stamp=1515504032&raw=0
[2] https://buildd.debian.org/status/logs.php?pkg=ros-bond-core
--
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
this unwanted
shadowing. (git2.h includes the other headers as "git2/*.h", so you
shouldn't need that flag.)
--
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
box) access...
[1] https://dsa.debian.org/doc/guest-account/
[2] https://db.debian.org/machines.cgi?sortby=architecture&sortorder=asc
--
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
ls, 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
principle strike elsewhere, including on release
architectures. To avoid it, I'd suggest simply arranging to run the
tests one at a time. (Running the remainder of the build in parallel
appears to be safe, though.)
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alu
Control: notfixed -1 4.17+dfsg-2
Control: found -1 4.17+dfsg-2
"Aaron M. Ucko" writes:
> Could you please take a look and account for this
> architecture-dependent variation one way or another?
Could you please also update symbols for the non-release architectures
hppa, m68k,
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
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
cipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2
--
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
risk
truncation (or, worse, overflows). However, if that's infeasible for
some reason, you can also look up _PC_PATH_MAX via pathconf or supply
a fallback constant definition (traditionally 4096).
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu,
or: unrecognized command line option '-mavx'
(On sh4, g++ suggests that -maes may have been a typo for the vaguely
similar-looking -m2e.)
Please refrain from using either flag on *any* architecture, since
they limit the portability of the resulting binaries.
Thanks!
--
Aaron M. Ucko, K
commission at the
moment, but I wouldn't be surprised if kFreeBSD builds turned out to
fail in the same fashion.
Could you please arrange to predefine WIN32 et al. only when actually
building for Windows?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
owerpc and powerpcspe, but I suspect builds
for a couple of non-release architectures that are currently failing
with compilation errors would also be affected if they got far enough.
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mi
: 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!
-
8k and powerpcspe, the (non-release) big-endian
architectures on which this ndpi version nominally built fine, both run
with nocheck in DEB_BUILD_OPTIONS, so we shouldn't read too much into
those successes.
--
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
either conditionalize the use of this option or restrict the
package's architecture setting appropriately.
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
- testConversion (Timeout)
23 - testMatrix (Timeout)
27 - testMatrixPseudoInverse (Timeout)
60 - testImgproc (Timeout)
80 - testKeyPoint-5 (Timeout)
81 - testKeyPoint-6 (Timeout)
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.
OPTIONS.)
* On s390x, these tests all encountered segmentation faults.
* On ppc64[*], these tests all failed with an unspecified "Exception:
Other".
Could you please take a look?
Thanks!
[*] Admittedly not a release architecture.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu,
ease 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
discrepancies, as
detailed at
https://buildd.debian.org/status/fetch.php?pkg=ndpi&arch=hppa&ver=2.2-1&stamp=1514679693&raw=0
As noted in #886133, it also took a really long time to complete
(roughly seven and a half hours).
Could you please take a look?
Thanks!
--
Aaron M. Ucko
suite discrepancies, as
detailed at
https://buildd.debian.org/status/fetch.php?pkg=ndpi&arch=alpha&ver=2.2-1&stamp=1514652572&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.mi
d ran for a
long time before terminating on its own (albeit with test suite
errors), so you may simply need to add progress indicators for the
sake of slow architectures. (These are inactivity timeouts, so any
output to stdout or stderr resets them.)
Could you please take a look?
Thanks!
--
Aa
cture: linux-any 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
points for additionally accounting for builds that cover only
the architecture-independent packages, as with dpkg-buildpackage -A
(allowing for source-only uploads). ;-)
Thanks!
FTR, I'm classifying this bug as a regression because it would affect
any needed binary-only rebuilds for am
erhaps 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
that build errors for
packages that have recently emerged from NEW don't accidentally escape
notice.
--
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
Scott Kitterman writes:
> Once I get all the build logs I'll update it later this week.
Great, thanks! Please note that kfreebsd-* builds appear unlikely to be
forthcoming any time soon, so you may still need to extrapolate there.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu,
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)
for function '_get_real_path'
[...]
It's great that directory-monitor.c already attempts to accommodate
systems like the Hurd with no fixed PATH_MAX, but there are a couple
of typos in the relevant code. Please try removing the unbalanced
(and unneeded) { on line 65 and fixing the spel
sqlite3.OperationalError: database is locked
as detailed at
https://buildd.debian.org/status/fetch.php?pkg=peewee&arch=hurd-i386&ver=2.10.2%2Bdfsg-2&stamp=1513960535&raw=0.
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
ht
lately:
{standard input}: Assembler messages:
{standard input}:5854: Error: unrecognized opcode: `ptesync'
/<>/scripts/Makefile.build:319: recipe for target
'arch/powerpc/lib/sstep.o' failed
make[6]: *** [arch/powerpc/lib/sstep.o] Error 1
Could you please take a look?
Error at CMakeLists.txt:39 (MESSAGE):
Neither uhid nor uinput was found
If support for these Linux APIs is essential, please formally restrict
the package's architecture to linux-any accordingly, so that other
architectures' autobuilders don't bother trying to cover it.
Thank
https://buildd.debian.org/status/logs.php?pkg=libnitrokey&ver=3.1-1
Could you please take a look and account for this variation (bearing
in mind that the details may turn out to be architecture-dependent)?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit
left out
earlier.
Thanks!
FTR, I'm filing this bug as a regression because it would affect any
needed binary-only rebuilds for amd64.
--
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
;s infeasible,
you can also look up _PC_PATH_MAX via pathconf or supply a fallback
constant (traditionally 4096).
Could you please take a look, bearing in mind that there's presumably
at least one more reference to PATH_MAX (in whatever calls
xpath_get_exec_path)?
Thanks!
--
Aaron M. Uc
/connector.h: No such file or directory
If extrace needs Linux-specific APIs, please formally limit its
Architecture field to linux-any so that autobuilders for other
architectures don't bother trying to cover it.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
s, you should be able to check for their existence
with corresponding #ifdef constructs.
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
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.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
notfixed -1 4.1.0~dfsg-1
found -1 4.1.0~dfsg-1
thanks
"Aaron M. Ucko" writes:
> This #include directive (and any corresponding code) is presumably
Thanks for looking into this bug, but you only took care of the #include
directive, not the corresponding code. Please also substit
hitecture-dependent variation one way or another?
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
Nikos Tsipinakis writes:
> Accidentally replied to the wrong bug, sorry about that. I'm still unsure
> about
> how to fix this one.
No problem. As for this one, perhaps running tests via
script -c '...' /dev/null
would help.
--
Aaron M. Ucko, KB1CJC (amu
der rand
Bus error
debian/rules:23: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 138
"Bus error" typically indicates unaligned memory access, about which
sparc64 is notoriously strict.
Could you please take a look?
Thanks
practice
is to work dynamically with what you encounter (for instance, with the
help of the glibc extension get_current_dir_name). However, if that's
infeasible, you can also look up _PC_PATH_MAX via pathconf or supply a
fallback constant (traditionally 4096).
Could you please take a look?
T
opening terminal: unknown.
debian/rules:23: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] 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.
/Scanner.o' failed
I presume wchar_t is unsigned on these architectures. Could you
please take a look and account for this possibility (or whatever the
problem turns out to be)?
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
PPFLAGS (which is
supposed to be for the C PreProcessor). It should properly consult both
CPPFLAGS and CXXFLAGS, and distribute its own flags across these two
variables as appropriate.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http:
s with -fPIE (via
pie-link.specs) but does not compile with any such option. (GCC, at
least in Debian, now defaults to -fPIE on most architectures, but not
yet on x32.)
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
orted"
Please either add proper Hurd support (which will likely look pretty
similar to Linux and kFreeBSD support, since all use GNU libc) or
formally restrict libzc's Architecture to linux-any kfreebsd-any so
that the Hurd autobuilders don't bother attempting to cover it.
Thanks!
--
A
: error: debian/rules build-arch subprocess returned exit
status 2
--
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
libesedb 20170121
# TOTAL: 4
# PASS: 1
# SKIP: 3
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
====
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit
Lisandro Damián Nicanor Pérez Meyer writes:
> El 15 dic. 2017 1:39 p.m., "Aaron M. Ucko" escribió:
>
[...]
> + /<>/qbs-1.8.1+dfsg/bin/qbs-setup-qt /usr/bin/qmake
> qbs_autotests
> Bus error
[...]
> In my experience bus errors are arch-related. Of course thi
you should be able to avoid hitting it by having
the test print progress indicators every so often. Still not a
priority, to be sure, but likely not too difficult.
--
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
there is much
> point doing any more work than versioning the dependency correctly. I
> guess they'll catch up eventually.
I agree that that's a fair tradeoff in this case; just please version
the B-D accordingly.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko
[check-ghc-stamp] 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.mit.edu/cgi/finger/?a...@monk.mit.edu
r risking truncation
(or, worse, overflow). However, if that's not feasible, you can also
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.
uild/protolib/src/common/protoAddress.cpp.1.o']
In file included from ../protolib/src/common/protoAddress.cpp:7:0:
/<>/norm-1.5r6+dfsg1/protolib/include/protoAddress.h:247:33: error:
field 'addr' has incomplete type 'sockaddr_storage'
Please note that the
suite, presumably due to a hang or infinite loop somewhere:
make check-TESTS
make[3]: Entering directory '/<>/warg/src'
make[4]: Entering directory '/<>/warg/src'
E: Build killed with signal TERM after 150 minutes of inactivity
Could you please take a l
7;; did you mean 'nice'?
[-Wimplicit-function-declaration]
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
ild failed before it could get to this point, due to
an unrelated error I'll report separately.)
Could you please take a look? You might consider simply versioning
the build dependency on default-jdk to (>= 2:1.8~) [note epoch!], as
available on all other architectures.
Thanks!
uld 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
istics match up.)
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
suite errors, as detailed at
https://buildd.debian.org/status/fetch.php?pkg=qbs&arch=hppa&ver=1.8.1%2Bdfsg-4&stamp=1505844196&raw=0:
Totals: 78 passed, 194 failed, 54 skipped, 0 blacklisted, 226338ms
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.
/processutils.cpp:61:5: error: #error Missing implementation of
processNameByPid for this platform.
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
t 'check' failed
make[5]: *** [check] Error 94
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
t:
cpp.architecture: you might want to re-run 'qbs-setup-toolchains'
debian/rules:30: recipe for target 'override_dh_auto_build' failed
Could you please take a look? If the problem turns out to lie in qbs,
please feel free to reassign this bug accordingly.
Thanks!
--
Aaron
u
probably ought to wait to see how at least one of those builds fares
before determining the minimum version. You could also of course test
on a kFreeBSD porter box, but I can't reach either at the moment.)
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum
if you weren't specifically looking for it -- particularly given that
the patch would have still helped the systems it was meant to, just at
the cost of breaking some others.
--
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: openafs
Version: 1.6.22-2
Severity: important
Tags: upstream
Thanks for looking into #884276. The module now builds successfully,
but encounters an Oops on load, as detailed below. The issue appears
to be that 0005-afs-fix-kernel_write-kernel_read-arguments.patch adds
a conditional defin
recipe for target 'test' failed
make[2]: *** [test] Error 8
The corresponding checks for narrower types all passed.
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
"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
keFiles/pdfdetach.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs
/usr/bin/ld: CMakeFiles/pdffonts.dir/parseargs.cc.o: relocation R_X86_64_32S
against `.rodata' can not be used when making a shared object; recompile with
-fPIC
/usr/bin/ld: CMakeFiles/pdffonts.dir/pdffonts.cc.o: re
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
`(%r11d,%rax)' is not a valid base/index expression
noise.c:248: Error: `(%edi,%rax)' is not a valid base/index expression
Makefile:761: recipe for target 'libpost_planar_asm_la-noise.lo' failed
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum
n (handle is not open for reading))
[...]
Finished in 0.0400 seconds
12 examples, 12 failures
Test suite test: FAIL
Could you please take a look? (The other 11 tests failed in the same
fashion.)
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.
e same overarching tree
(NCBI's C++ Toolkit) as BLAST+, it is a separate project. The packaging
work done for BLAST+ would make for a decent starting point, though.
Meanwhile, what ever happened with https://bugs.debian.org/682042 ? ;-)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, u
inux-any and be done
with 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
can arrange to add support for either or both kernels, great.
Otherwise, I'd suggest declaring Architecture: linux-any so that
non-Linux autobuilders don't bother attempting to cover i2c-tools.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mi
ugs
based on buildd.d.o logs for source packages that recently introduced
new binary packages to unstable for amd64 or i386.)
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
':
./avcall/./avcall-compat.c:24: multiple definition of `__builtin_avcall'
.libs/avcall-powerpc.o:avcall-powerpc.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at
executable...
E: Build killed with signal TERM after 600 minutes of inactivity
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
301 - 400 of 3066 matches
Mail list logo