Discussion:
[Buildroot] [autobuild.buildroot.net] Build results for 2018-10-09
Thomas Petazzoni
2018-10-10 06:00:10 UTC
Permalink
Hello,

Build statistics for 2018-10-09
===============================

branch | OK | NOK | TIM | TOT |
2018.02.x | 16 | 1 | 0 | 17 |
2018.08.x | 29 | 1 | 0 | 30 |
master | 187 | 68 | 0 | 255 |

Results for branch '2018.02.x'
==============================

Classification of failures by reason
------------------------------------

boost-1.66.0 | 1


Detail of failures
------------------

powerpc | boost-1.66.0 | NOK | http://autobuild.buildroot.net/results/f93ef5916bbc7931809f34cef54d125c02e8b176 |

Results for branch '2018.08.x'
==============================

Classification of failures by reason
------------------------------------

wireshark-2.2.16 | 1


Detail of failures
------------------

mipsel | wireshark-2.2.16 | NOK | http://autobuild.buildroot.net/results/7bc9dd7385ce6a98e3e74d7d48d6aed75c03018d | ORPH

Results for branch 'master'
===========================

Classification of failures by reason
------------------------------------

target-finalize | 18
ptpd2-ptpd-2.3.1 | 7
collectd-5.7.1 | 4
Makefile:709: target-finalize | 4
docker-containerd-v1.1.3 | 3
gpsd-3.18 | 3
boost-1.68.0 | 2
brltty-5.6 | 2
libmpeg2-0.5.1 | 2
qt5base-5.11.2 | 2
qt5webkit-5.9.1 | 2
vlc-3.0.4 | 2
boa-0.94.14rc21 | 1
erlang-21.0 | 1
glibc-legal-info | 1
gst-plugins-bad-0.10.23 | 1
host-go-1.11 | 1
luvi-v2.8.0 | 1
minizip-2.5.3 | 1
motion-release-4.1.1 | 1
netsnmp-5.8 | 1
open-plc-utils-1be781d1ea81... | 1
package/glibc/glibc.mk:143:... | 1
php-7.2.10 | 1
spandsp-20180108 | 1
squid-4.2 | 1
traceroute-2.1.0 | 1
util-linux-2.32.1 | 1
wireshark-2.2.16 | 1


Detail of failures
------------------

arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
i686 | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/1ceed7d91627711c12c4866fa6672a02fc6ddc8c |
arm | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f |
mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/7187e560e66f2bd6073b5510e2782ebdaccfb4a9 |
mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/5f8e8b8517fda50a2e98a456933260f08054356d |
aarch64 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/24a280d6233b3284edd44c4528d8799c6894c11a | ORPH
sh4 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/63a4f980d7cdb4b0823840f747589803fcd0d69f | ORPH
arc | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/1a6f2fcf1a88ecc5b598dd11c5914dcacf0e1e6b | ORPH
arm | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/b0829bc3343d6dc3065078e94896725b1c808bc1 | ORPH
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b |
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da |
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c |
x86_64 | erlang-21.0 | NOK | http://autobuild.buildroot.net/results/fc633f80c7c36a90e641487f5a888fbb767c2a54 |
arc | glibc-legal-info | NOK | http://autobuild.buildroot.net/results/64c70d82c857c272df171ae6783629c1ba92d812 | ORPH
mips64el | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/c00d22a6dcadb82a19afab6eacea654d3c41b4c5 | ORPH
powerpc | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/18599ea12a35b9715a67c1f4e5c4e56906235c94 | ORPH
arm | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/a13a5d852c83cd1fc9f2d1fc2b7302db515278b8 | ORPH
mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
arm | host-go-1.11 | NOK | http://autobuild.buildroot.net/results/8d3af6f00bf34737faabc21bdccf7d025462fec7 |
powerpc | libmpeg2-0.5.1 | NOK | http://autobuild.buildroot.net/results/69f52854b222b5be1a981b96a804098fec5a849b | ORPH
powerpc | libmpeg2-0.5.1 | NOK | http://autobuild.buildroot.net/results/eb8dc1e67eae123a823fadc17ca7611c2cc7f621 | ORPH
arm | luvi-v2.8.0 | NOK | http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886 |
aarch64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/dcbbae0180bc597c58fc694c3006b623633aab7f |
aarch64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/cef7e38fbd4de65d1830f681a497bc007a897502 |
arm | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/62143510a7ede7d92f55e908306bc367586c2748 |
sparc64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/d0c1aa394745ba48d832cc77c23721ca6b453d23 |
m68k | minizip-2.5.3 | NOK | http://autobuild.buildroot.net/results/78b8eb0f9f7f2963f0056834054f16e764bc3106 |
powerpc | motion-release-4.1.1 | NOK | http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5 |
arm | netsnmp-5.8 | NOK | http://autobuild.buildroot.net/results/9f02e0f09ae2d2a66a8d33d73f1bdd45ea8b0f16 | ORPH
arm | open-plc-utils-1be781d1ea81... | NOK | http://autobuild.buildroot.net/results/67bc5e7ac8ae1c49c035b022a394d2f746705cf2 |
arc | package/glibc/glibc.mk:143:... | NOK | http://autobuild.buildroot.net/results/4a1ddb5c0afb1e80ac769d36cb720372f7bb5457 |
arm | php-7.2.10 | NOK | http://autobuild.buildroot.net/results/7b7e25bfd269f7c252d15ab4e9f1b68348823478 | ORPH
microblazeel | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/1c00bfa77c38f0aad7643344b16d8f401c9b927a | ORPH
arm | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/298fda61ab5a192c235027e1b4c57aba4e6b8b37 | ORPH
mips64el | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/8fe8061cb27cbab8f02e6dfb0a870d76be3f7f3e | ORPH
xtensa | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/80b014e965b088e6767af671d39657b415f82453 | ORPH
mipsel | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/40f1090a0eb720d4cce2715bca51823213efb9f9 | ORPH
arm | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/55933c2c4ecf8a84b283c93adf0c2ed8a4f03301 | ORPH
mips64el | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/08d40b95945ed0e61805b07446b5eb5731f23198 | ORPH
aarch64_be | qt5base-5.11.2 | NOK | http://autobuild.buildroot.net/results/aeddb85c0262cdc23019c72e1c390d3885cb4ae4 |
aarch64_be | qt5base-5.11.2 | NOK | http://autobuild.buildroot.net/results/5bec7d7f14befa3a03f902ef90cc2c6589943ec2 |
mipsel | qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/7aca204c7fd486def6306412b0a6e0bfb8234786 |
arm | qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/b8ae1b94891206746815fa85fafabfbd6bed8c74 |
arm | spandsp-20180108 | NOK | http://autobuild.buildroot.net/results/05885325ec274cb9860d423c57eed5e7063aedc0 |
powerpc | squid-4.2 | NOK | http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751 | ORPH
microblazeel | target-finalize | NOK | http://autobuild.buildroot.net/results/068fa36a0be7a2207144cfcc9d595d6099bd9e39 |
xtensa | target-finalize | NOK | http://autobuild.buildroot.net/results/3b17b82658842849cf72d01b6f6a4f735e13a642 |
xtensa | target-finalize | NOK | http://autobuild.buildroot.net/results/c76bf4a1902da001de673c2160e7f68f83072feb |
mips | target-finalize | NOK | http://autobuild.buildroot.net/results/a0f68aba5c02cbf053c0a425667f1393ef71a0e5 |
arc | target-finalize | NOK | http://autobuild.buildroot.net/results/21adc28431f328526d88158e98e84b2fab2e4275 |
mipsel | target-finalize | NOK | http://autobuild.buildroot.net/results/0bf569d8d0ae380bdd1c8b6ddfa111e85670e981 |
powerpc | target-finalize | NOK | http://autobuild.buildroot.net/results/f92fd883386a547d42e0c699f7db859f2918e3f2 |
powerpc | target-finalize | NOK | http://autobuild.buildroot.net/results/ca096daed97a11b9be1618bd284b626527414e88 |
arm | target-finalize | NOK | http://autobuild.buildroot.net/results/8b4ce48f1b612710b8f2bb1b4ca3b203e1ed6293 |
aarch64 | target-finalize | NOK | http://autobuild.buildroot.net/results/797e736dc81d84e63a9293a7b1b62d7d4ae29194 |
arc | target-finalize | NOK | http://autobuild.buildroot.net/results/dd94cc60c4eb5a102b04db52b0ee2c7417c0c2f5 |
x86_64 | target-finalize | NOK | http://autobuild.buildroot.net/results/8329204dc3737635b92c2fdef224992f3c302f0c |
arm | target-finalize | NOK | http://autobuild.buildroot.net/results/5ab016529d2ec177f2865ac184d4a91149a649db |
aarch64_be | target-finalize | NOK | http://autobuild.buildroot.net/results/b8e27bd74c40cbc6f6ed9c5df4f0021af4fda050 |
mips64el | target-finalize | NOK | http://autobuild.buildroot.net/results/a5f6626116e8e721d5f6eb1d0aebf4656b9452f0 |
arm | target-finalize | NOK | http://autobuild.buildroot.net/results/89b5cc38f7b45046417fa20bbd8078646e9c39ef |
aarch64 | target-finalize | NOK | http://autobuild.buildroot.net/results/a28d07fd7999f1505a346598ea62ac3c212db7a2 |
arc | target-finalize | NOK | http://autobuild.buildroot.net/results/c905171b7a2beb768e23c7b834c50df0764500e1 |
arc | traceroute-2.1.0 | NOK | http://autobuild.buildroot.net/results/22855418dcb5bca4b6499991bc810b368a0cfcd5 |
powerpc64le | util-linux-2.32.1 | NOK | http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b |
mips | vlc-3.0.4 | NOK | http://autobuild.buildroot.net/results/6662b312a99955fccc924ffd831d31c3f5b93b9f |
nios2 | vlc-3.0.4 | NOK | http://autobuild.buildroot.net/results/441a7d1b875549013a30e70d6bb425892392e403 |
arc | wireshark-2.2.16 | NOK | http://autobuild.buildroot.net/results/829fb15eac2b16943c366ac82b260831de882149 | ORPH
--
http://autobuild.buildroot.net
Thomas Petazzoni
2018-10-10 15:48:14 UTC
Permalink
Hello,

Here is an analysis of yesterday build results. Johan, Frank,
Christian, Fabrice, Peter, Matt, Bernd, Giulio, Baruch, you are in Cc
because there are questions/issues for you below. Thanks! :-)
Post by Thomas Petazzoni
master | 187 | 68 | 0 | 255 |
These results are not very good, let's have a look at what's going on,
and try to get everyone to help fixing those issues.
Post by Thomas Petazzoni
arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
(cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
make: unrecognized option '--jobserver-fds=6,7'

This suddenly started happening on September 9, 2018. We have not
bumped boa. I'm not sure what caused this. It fails on different
autobuilder machines. Boa is calling submake with $(MFLAGS), which is
probably the issue, but why did this suddenly started to happen ?

With a minimal configuration with just Boa, I cannot reproduce on my
machine here, neither on my autobuilder where the problem is reported
to occur.
Post by Thomas Petazzoni
i686 | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/1ceed7d91627711c12c4866fa6672a02fc6ddc8c |
libboost_chrono shouldn't have been installed: missing select in boost/Config.in
Post by Thomas Petazzoni
arm | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f |
libboost_atomic shouldn't have been installed: missing select in boost/Config.in

Fabrice, these two are for you :)
Post by Thomas Petazzoni
mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/7187e560e66f2bd6073b5510e2782ebdaccfb4a9 |
mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/5f8e8b8517fda50a2e98a456933260f08054356d |
Those should be fixed by
https://git.buildroot.org/buildroot/commit/?id=9143c217213542574586c0e6a9f003e822633917.
Post by Thomas Petazzoni
aarch64 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/24a280d6233b3284edd44c4528d8799c6894c11a | ORPH
sh4 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/63a4f980d7cdb4b0823840f747589803fcd0d69f | ORPH
arc | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/1a6f2fcf1a88ecc5b598dd11c5914dcacf0e1e6b | ORPH
arm | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/b0829bc3343d6dc3065078e94896725b1c808bc1 | ORPH
Fixed by
https://git.buildroot.org/buildroot/commit/package/collectd?id=d65ea85fddaf64a7762f958d1ce9fb33997648d3
Post by Thomas Petazzoni
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b |
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da |
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c |
/home/naourr/work/instance-3/output/host/lib/go/pkg/tool/linux_amd64/link: running /home/naourr/work/instance-3/output/host/bin/x86_64-amd-linux-gnu-gcc failed: exit status 1
/tmp/go-build283204336/b001/exe/a.out: final close failed: Invalid operation

Christian, what is happening here? Could you have a look?
Post by Thomas Petazzoni
x86_64 | erlang-21.0 | NOK | http://autobuild.buildroot.net/results/fc633f80c7c36a90e641487f5a888fbb767c2a54 |
In file included from zlib/adler32.c:11:0:
zlib/zutil.h:172:39: error: "_LFS64_LARGEFILE" is not defined [-Werror=undef]
(!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)

Seems like a musl/erlang issue. Johan, Frank, could you have a look ?
Post by Thomas Petazzoni
arc | glibc-legal-info | NOK | http://autobuild.buildroot.net/results/64c70d82c857c272df171ae6783629c1ba92d812 | ORPH
Fixed by
https://git.buildroot.org/buildroot/commit/?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e.
Post by Thomas Petazzoni
mips64el | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/c00d22a6dcadb82a19afab6eacea654d3c41b4c5 | ORPH
powerpc | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/18599ea12a35b9715a67c1f4e5c4e56906235c94 | ORPH
arm | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/a13a5d852c83cd1fc9f2d1fc2b7302db515278b8 | ORPH
Fixed by https://git.buildroot.org/buildroot/commit/package/gpsd?id=ae2a91322aeaa72d6f5354312056d16dc275470d
Post by Thomas Petazzoni
mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
if (plc->plc_state->missing_samples != 0)

Peter (Seiderer) ?
Post by Thomas Petazzoni
arm | host-go-1.11 | NOK | http://autobuild.buildroot.net/results/8d3af6f00bf34737faabc21bdccf7d025462fec7 |
fatal error: unexpected signal during runtime execution
[signal SIGBUS: bus error code=0x2 addr=0xc000800010 pc=0x42098d]

This particular issue seems to happen only on Matt autobuilder. Matt,
can you check if you can reproduce it reliably ?
Post by Thomas Petazzoni
powerpc | libmpeg2-0.5.1 | NOK | http://autobuild.buildroot.net/results/69f52854b222b5be1a981b96a804098fec5a849b | ORPH
powerpc | libmpeg2-0.5.1 | NOK | http://autobuild.buildroot.net/results/eb8dc1e67eae123a823fadc17ca7611c2cc7f621 | ORPH
motion_comp_altivec.c:48:12: internal compiler error: Segmentation fault
return vec_ld (A, (uint8_t *)B);

Bernd, could you have a look at this PowerPC/Altivec issue ?
Post by Thomas Petazzoni
arm | luvi-v2.8.0 | NOK | http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886 |
luvi 2.8.0 fails to build. Bernd, you bumped this package, and Jörg
suggested to revert the bump. Could you discuss this, and provide a fix?
Post by Thomas Petazzoni
aarch64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/dcbbae0180bc597c58fc694c3006b623633aab7f |
aarch64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/cef7e38fbd4de65d1830f681a497bc007a897502 |
arm | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/62143510a7ede7d92f55e908306bc367586c2748 |
sparc64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/d0c1aa394745ba48d832cc77c23721ca6b453d23 |
See below "target-finalize"
Post by Thomas Petazzoni
m68k | minizip-2.5.3 | NOK | http://autobuild.buildroot.net/results/78b8eb0f9f7f2963f0056834054f16e764bc3106 |
/home/buildroot/build/instance-0/output/host/m68k-buildroot-linux-uclibc/sysroot/usr/lib/libbsd.so: undefined reference to `__register_atfork'
collect2: error: ld returned 1 exit status

I guess it would be fixed by http://patchwork.ozlabs.org/patch/978465/.
Someone needs to review this.
Post by Thomas Petazzoni
powerpc | motion-release-4.1.1 | NOK | http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5 |
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/powerpc-buildroot-linux-uclibc/sysroot/usr/lib/libavutil.a(hwcontext_drm.o): In function `drm_device_create':
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:50: undefined reference to `drmGetVersion'
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:63: undefined reference to `drmFreeVersion'

Giulio, I believe you worked on this static linking problem between
ffmpeg and libdrm. What is the status of this ?
Post by Thomas Petazzoni
arm | netsnmp-5.8 | NOK | http://autobuild.buildroot.net/results/9f02e0f09ae2d2a66a8d33d73f1bdd45ea8b0f16 | ORPH
configure: error: The DTLS based transports require the libssl library from OpenSSL to be available and support DTLS

Bernd, you did the last version bump of netsnmp, could you have a look ?
Post by Thomas Petazzoni
arm | open-plc-utils-1be781d1ea81... | NOK | http://autobuild.buildroot.net/results/67bc5e7ac8ae1c49c035b022a394d2f746705cf2 |
I assume this would be fixed by
http://patchwork.ozlabs.org/patch/981495/.
Post by Thomas Petazzoni
arc | package/glibc/glibc.mk:143:... | NOK | http://autobuild.buildroot.net/results/4a1ddb5c0afb1e80ac769d36cb720372f7bb5457 |
Fixed by
https://git.buildroot.org/buildroot/commit/package/glibc?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e.
Post by Thomas Petazzoni
arm | php-7.2.10 | NOK | http://autobuild.buildroot.net/results/7b7e25bfd269f7c252d15ab4e9f1b68348823478 | ORPH
multiple definition of `icu_60::MessageFormatAdapter::getArgTypeList(icu_60::MessageFormat const&, int&)'

Long standing issue. Anyone brave enough to investigate ?
Post by Thomas Petazzoni
microblazeel | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/1c00bfa77c38f0aad7643344b16d8f401c9b927a | ORPH
arm | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/298fda61ab5a192c235027e1b4c57aba4e6b8b37 | ORPH
mips64el | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/8fe8061cb27cbab8f02e6dfb0a870d76be3f7f3e | ORPH
xtensa | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/80b014e965b088e6767af671d39657b415f82453 | ORPH
mipsel | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/40f1090a0eb720d4cce2715bca51823213efb9f9 | ORPH
arm | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/55933c2c4ecf8a84b283c93adf0c2ed8a4f03301 | ORPH
mips64el | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/08d40b95945ed0e61805b07446b5eb5731f23198 | ORPH
Should be fixed by http://patchwork.ozlabs.org/patch/964746/. I haven't
had the chance to review it.
Post by Thomas Petazzoni
aarch64_be | qt5base-5.11.2 | NOK | http://autobuild.buildroot.net/results/aeddb85c0262cdc23019c72e1c390d3885cb4ae4 |
aarch64_be | qt5base-5.11.2 | NOK | http://autobuild.buildroot.net/results/5bec7d7f14befa3a03f902ef90cc2c6589943ec2 |
/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64_be-linux-gnu/7.3.1/../../../../aarch64_be-linux-gnu/bin/ld.gold: internal error in update_erratum_insn, at /home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64_be-linux-gnu/snapshots/binutils-gdb.git~users~linaro~binutils-2_28-branch/gold/aarch64.cc:998

Compiler bug it seems. Anyone to have a look ?
Post by Thomas Petazzoni
mipsel | qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/7aca204c7fd486def6306412b0a6e0bfb8234786 |
{standard input}: Assembler messages:
{standard input}:708: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v0,$t8,$t7'
{standard input}:759: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v1,$t8,$t7'
{standard input}:765: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $t2,$t8,$t7'

We should disable qt5webkit on mips32r6. Peter ?
Post by Thomas Petazzoni
arm | qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/b8ae1b94891206746815fa85fafabfbd6bed8c74 |
/home/naourr/work/instance-3/output/build/qt5webkit-5.9.1/Source/WebCore//.obj/platform/leveldb/LevelDBDatabase.o: In function `WebCore::LevelDBDatabase::openInMemory(WebCore::LevelDBComparator const*)':
LevelDBDatabase.cpp:(.text._ZN7WebCore15LevelDBDatabase12openInMemoryEPKNS_17LevelDBComparatorE+0x22): undefined reference to `leveldb::NewMemEnv(leveldb::Env*)'

Ah, yes, we have a patch fixing that in patchwork. I don't like it a
lot, but I guess that's the only option.
Post by Thomas Petazzoni
arm | spandsp-20180108 | NOK | http://autobuild.buildroot.net/results/05885325ec274cb9860d423c57eed5e7063aedc0 |
checking for TIFFOpen in -ltiff... no
configure: error: "Cannot build without libtiff (does your system require a libtiff-devel package?)"

Bernd, you added spandsp recently, could you have a look ?
Post by Thomas Petazzoni
powerpc | squid-4.2 | NOK | http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751 | ORPH
../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0' is allowed) before ';' token
../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0' is allowed) before ';' token

Not sure. Baruch, you recently bumped the squid package, could you have
a look ?
Post by Thomas Petazzoni
microblazeel | target-finalize | NOK | http://autobuild.buildroot.net/results/068fa36a0be7a2207144cfcc9d595d6099bd9e39 |
xtensa | target-finalize | NOK | http://autobuild.buildroot.net/results/3b17b82658842849cf72d01b6f6a4f735e13a642 |
xtensa | target-finalize | NOK | http://autobuild.buildroot.net/results/c76bf4a1902da001de673c2160e7f68f83072feb |
mips | target-finalize | NOK | http://autobuild.buildroot.net/results/a0f68aba5c02cbf053c0a425667f1393ef71a0e5 |
arc | target-finalize | NOK | http://autobuild.buildroot.net/results/21adc28431f328526d88158e98e84b2fab2e4275 |
mipsel | target-finalize | NOK | http://autobuild.buildroot.net/results/0bf569d8d0ae380bdd1c8b6ddfa111e85670e981 |
powerpc | target-finalize | NOK | http://autobuild.buildroot.net/results/f92fd883386a547d42e0c699f7db859f2918e3f2 |
powerpc | target-finalize | NOK | http://autobuild.buildroot.net/results/ca096daed97a11b9be1618bd284b626527414e88 |
arm | target-finalize | NOK | http://autobuild.buildroot.net/results/8b4ce48f1b612710b8f2bb1b4ca3b203e1ed6293 |
aarch64 | target-finalize | NOK | http://autobuild.buildroot.net/results/797e736dc81d84e63a9293a7b1b62d7d4ae29194 |
arc | target-finalize | NOK | http://autobuild.buildroot.net/results/dd94cc60c4eb5a102b04db52b0ee2c7417c0c2f5 |
x86_64 | target-finalize | NOK | http://autobuild.buildroot.net/results/8329204dc3737635b92c2fdef224992f3c302f0c |
arm | target-finalize | NOK | http://autobuild.buildroot.net/results/5ab016529d2ec177f2865ac184d4a91149a649db |
aarch64_be | target-finalize | NOK | http://autobuild.buildroot.net/results/b8e27bd74c40cbc6f6ed9c5df4f0021af4fda050 |
mips64el | target-finalize | NOK | http://autobuild.buildroot.net/results/a5f6626116e8e721d5f6eb1d0aebf4656b9452f0 |
arm | target-finalize | NOK | http://autobuild.buildroot.net/results/89b5cc38f7b45046417fa20bbd8078646e9c39ef |
aarch64 | target-finalize | NOK | http://autobuild.buildroot.net/results/a28d07fd7999f1505a346598ea62ac3c212db7a2 |
arc | target-finalize | NOK | http://autobuild.buildroot.net/results/c905171b7a2beb768e23c7b834c50df0764500e1 |
I had a look at those 22 (18+4) failures, and all of them are caused either by
pysnmp or psycopg2 issues with Python 3.7.0. pysnmp was fixed today
(https://git.buildroot.org/buildroot/commit/?id=8122a1d85b6cc9f2adcb1243521c04ba4cae0510).
So the only package remaining package to fix is psycopg2.

Asaf, Yegor, Adam, could one of you take care of fixing psycopg2 soon ?

Related to this, I find it a bit annoying that all those issues are
detected at the target-finalize step, since package maintainers are not
properly notified. Should we move the byte-compile step as the end of
each Python package installation, so that if it fails, it fails
earlier, and within the context of that package ? Is the
byte-compilation process smart enough to skip compiling when a .pyc
file already exists and is newer than the matching .py file ? It would
be interesting to do a time comparison between doing per-package
byte-compilation and one global byte-compilation at the end.
Post by Thomas Petazzoni
arc | traceroute-2.1.0 | NOK | http://autobuild.buildroot.net/results/22855418dcb5bca4b6499991bc810b368a0cfcd5 |
make[3]: *** No rule to make target '-lm', needed by 'traceroute'. Stop.
make[3]: *** Waiting for unfinished jobs....

Meh ?
Post by Thomas Petazzoni
powerpc64le | util-linux-2.32.1 | NOK | http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b |
checking for SELINUX... no
configure: error: SELinux selected but libselinux not found or too old

We've been having this one for a while. Could some SELinux person
(Matt ? Adam ?) debug this ?
Post by Thomas Petazzoni
mips | vlc-3.0.4 | NOK | http://autobuild.buildroot.net/results/6662b312a99955fccc924ffd831d31c3f5b93b9f |
nios2 | vlc-3.0.4 | NOK | http://autobuild.buildroot.net/results/441a7d1b875549013a30e70d6bb425892392e403 |
codec/.libs/libvorbis_plugin_la-vorbis.o: In function `Encode':
vorbis.c:(.text+0x1a8): undefined reference to `vorbis_analysis_buffer'

Bernd ?
Post by Thomas Petazzoni
arc | wireshark-2.2.16 | NOK | http://autobuild.buildroot.net/results/829fb15eac2b16943c366ac82b260831de882149 | ORPH
/home/buildroot/autobuild/run/instance-0/output/host/arc-buildroot-linux-gnu/include/c++/7.3.1/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>

Meh, weird. Anyone ?

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Matthew Weber
2018-10-10 16:28:39 UTC
Permalink
Thomas,


On Wed, Oct 10, 2018 at 10:48 AM Thomas Petazzoni
Post by Thomas Petazzoni
Hello,
Here is an analysis of yesterday build results. Johan, Frank,
Christian, Fabrice, Peter, Matt, Bernd, Giulio, Baruch, you are in Cc
because there are questions/issues for you below. Thanks! :-)
Post by Thomas Petazzoni
master | 187 | 68 | 0 | 255 |
These results are not very good, let's have a look at what's going on,
and try to get everyone to help fixing those issues.
Post by Thomas Petazzoni
arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
(cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
make: unrecognized option '--jobserver-fds=6,7'
This suddenly started happening on September 9, 2018. We have not
bumped boa. I'm not sure what caused this. It fails on different
autobuilder machines. Boa is calling submake with $(MFLAGS), which is
probably the issue, but why did this suddenly started to happen ?
With a minimal configuration with just Boa, I cannot reproduce on my
machine here, neither on my autobuilder where the problem is reported
to occur.
Post by Thomas Petazzoni
i686 | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/1ceed7d91627711c12c4866fa6672a02fc6ddc8c |
libboost_chrono shouldn't have been installed: missing select in boost/Config.in
Post by Thomas Petazzoni
arm | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f |
libboost_atomic shouldn't have been installed: missing select in boost/Config.in
Fabrice, these two are for you :)
Post by Thomas Petazzoni
mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/7187e560e66f2bd6073b5510e2782ebdaccfb4a9 |
mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/5f8e8b8517fda50a2e98a456933260f08054356d |
Those should be fixed by
https://git.buildroot.org/buildroot/commit/?id=9143c217213542574586c0e6a9f003e822633917.
Post by Thomas Petazzoni
aarch64 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/24a280d6233b3284edd44c4528d8799c6894c11a | ORPH
sh4 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/63a4f980d7cdb4b0823840f747589803fcd0d69f | ORPH
arc | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/1a6f2fcf1a88ecc5b598dd11c5914dcacf0e1e6b | ORPH
arm | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/b0829bc3343d6dc3065078e94896725b1c808bc1 | ORPH
Fixed by
https://git.buildroot.org/buildroot/commit/package/collectd?id=d65ea85fddaf64a7762f958d1ce9fb33997648d3
Post by Thomas Petazzoni
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b |
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da |
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c |
/home/naourr/work/instance-3/output/host/lib/go/pkg/tool/linux_amd64/link: running /home/naourr/work/instance-3/output/host/bin/x86_64-amd-linux-gnu-gcc failed: exit status 1
/tmp/go-build283204336/b001/exe/a.out: final close failed: Invalid operation
Christian, what is happening here? Could you have a look?
Post by Thomas Petazzoni
x86_64 | erlang-21.0 | NOK | http://autobuild.buildroot.net/results/fc633f80c7c36a90e641487f5a888fbb767c2a54 |
zlib/zutil.h:172:39: error: "_LFS64_LARGEFILE" is not defined [-Werror=undef]
(!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
Seems like a musl/erlang issue. Johan, Frank, could you have a look ?
Post by Thomas Petazzoni
arc | glibc-legal-info | NOK | http://autobuild.buildroot.net/results/64c70d82c857c272df171ae6783629c1ba92d812 | ORPH
Fixed by
https://git.buildroot.org/buildroot/commit/?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e.
Post by Thomas Petazzoni
mips64el | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/c00d22a6dcadb82a19afab6eacea654d3c41b4c5 | ORPH
powerpc | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/18599ea12a35b9715a67c1f4e5c4e56906235c94 | ORPH
arm | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/a13a5d852c83cd1fc9f2d1fc2b7302db515278b8 | ORPH
Fixed by https://git.buildroot.org/buildroot/commit/package/gpsd?id=ae2a91322aeaa72d6f5354312056d16dc275470d
Post by Thomas Petazzoni
mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
if (plc->plc_state->missing_samples != 0)
Peter (Seiderer) ?
Post by Thomas Petazzoni
arm | host-go-1.11 | NOK | http://autobuild.buildroot.net/results/8d3af6f00bf34737faabc21bdccf7d025462fec7 |
fatal error: unexpected signal during runtime execution
[signal SIGBUS: bus error code=0x2 addr=0xc000800010 pc=0x42098d]
This particular issue seems to happen only on Matt autobuilder. Matt,
can you check if you can reproduce it reliably ?
I'll take a look.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc | libmpeg2-0.5.1 | NOK | http://autobuild.buildroot.net/results/69f52854b222b5be1a981b96a804098fec5a849b | ORPH
powerpc | libmpeg2-0.5.1 | NOK | http://autobuild.buildroot.net/results/eb8dc1e67eae123a823fadc17ca7611c2cc7f621 | ORPH
motion_comp_altivec.c:48:12: internal compiler error: Segmentation fault
return vec_ld (A, (uint8_t *)B);
Bernd, could you have a look at this PowerPC/Altivec issue ?
Post by Thomas Petazzoni
arm | luvi-v2.8.0 | NOK | http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886 |
luvi 2.8.0 fails to build. Bernd, you bumped this package, and Jörg
suggested to revert the bump. Could you discuss this, and provide a fix?
Post by Thomas Petazzoni
aarch64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/dcbbae0180bc597c58fc694c3006b623633aab7f |
aarch64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/cef7e38fbd4de65d1830f681a497bc007a897502 |
arm | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/62143510a7ede7d92f55e908306bc367586c2748 |
sparc64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/d0c1aa394745ba48d832cc77c23721ca6b453d23 |
See below "target-finalize"
Post by Thomas Petazzoni
m68k | minizip-2.5.3 | NOK | http://autobuild.buildroot.net/results/78b8eb0f9f7f2963f0056834054f16e764bc3106 |
/home/buildroot/build/instance-0/output/host/m68k-buildroot-linux-uclibc/sysroot/usr/lib/libbsd.so: undefined reference to `__register_atfork'
collect2: error: ld returned 1 exit status
I guess it would be fixed by http://patchwork.ozlabs.org/patch/978465/.
Someone needs to review this.
Post by Thomas Petazzoni
powerpc | motion-release-4.1.1 | NOK | http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5 |
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:50: undefined reference to `drmGetVersion'
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:63: undefined reference to `drmFreeVersion'
Giulio, I believe you worked on this static linking problem between
ffmpeg and libdrm. What is the status of this ?
Post by Thomas Petazzoni
arm | netsnmp-5.8 | NOK | http://autobuild.buildroot.net/results/9f02e0f09ae2d2a66a8d33d73f1bdd45ea8b0f16 | ORPH
configure: error: The DTLS based transports require the libssl library from OpenSSL to be available and support DTLS
Bernd, you did the last version bump of netsnmp, could you have a look ?
Post by Thomas Petazzoni
arm | open-plc-utils-1be781d1ea81... | NOK | http://autobuild.buildroot.net/results/67bc5e7ac8ae1c49c035b022a394d2f746705cf2 |
I assume this would be fixed by
http://patchwork.ozlabs.org/patch/981495/.
Post by Thomas Petazzoni
arc | package/glibc/glibc.mk:143:... | NOK | http://autobuild.buildroot.net/results/4a1ddb5c0afb1e80ac769d36cb720372f7bb5457 |
Fixed by
https://git.buildroot.org/buildroot/commit/package/glibc?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e.
Post by Thomas Petazzoni
arm | php-7.2.10 | NOK | http://autobuild.buildroot.net/results/7b7e25bfd269f7c252d15ab4e9f1b68348823478 | ORPH
multiple definition of `icu_60::MessageFormatAdapter::getArgTypeList(icu_60::MessageFormat const&, int&)'
Long standing issue. Anyone brave enough to investigate ?
Post by Thomas Petazzoni
microblazeel | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/1c00bfa77c38f0aad7643344b16d8f401c9b927a | ORPH
arm | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/298fda61ab5a192c235027e1b4c57aba4e6b8b37 | ORPH
mips64el | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/8fe8061cb27cbab8f02e6dfb0a870d76be3f7f3e | ORPH
xtensa | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/80b014e965b088e6767af671d39657b415f82453 | ORPH
mipsel | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/40f1090a0eb720d4cce2715bca51823213efb9f9 | ORPH
arm | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/55933c2c4ecf8a84b283c93adf0c2ed8a4f03301 | ORPH
mips64el | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/08d40b95945ed0e61805b07446b5eb5731f23198 | ORPH
Should be fixed by http://patchwork.ozlabs.org/patch/964746/. I haven't
had the chance to review it.
Post by Thomas Petazzoni
aarch64_be | qt5base-5.11.2 | NOK | http://autobuild.buildroot.net/results/aeddb85c0262cdc23019c72e1c390d3885cb4ae4 |
aarch64_be | qt5base-5.11.2 | NOK | http://autobuild.buildroot.net/results/5bec7d7f14befa3a03f902ef90cc2c6589943ec2 |
/home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64_be-linux-gnu/7.3.1/../../../../aarch64_be-linux-gnu/bin/ld.gold: internal error in update_erratum_insn, at /home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64_be-linux-gnu/snapshots/binutils-gdb.git~users~linaro~binutils-2_28-branch/gold/aarch64.cc:998
Compiler bug it seems. Anyone to have a look ?
Post by Thomas Petazzoni
mipsel | qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/7aca204c7fd486def6306412b0a6e0bfb8234786 |
{standard input}:708: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v0,$t8,$t7'
{standard input}:759: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v1,$t8,$t7'
{standard input}:765: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $t2,$t8,$t7'
We should disable qt5webkit on mips32r6. Peter ?
Post by Thomas Petazzoni
arm | qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/b8ae1b94891206746815fa85fafabfbd6bed8c74 |
LevelDBDatabase.cpp:(.text._ZN7WebCore15LevelDBDatabase12openInMemoryEPKNS_17LevelDBComparatorE+0x22): undefined reference to `leveldb::NewMemEnv(leveldb::Env*)'
Ah, yes, we have a patch fixing that in patchwork. I don't like it a
lot, but I guess that's the only option.
Post by Thomas Petazzoni
arm | spandsp-20180108 | NOK | http://autobuild.buildroot.net/results/05885325ec274cb9860d423c57eed5e7063aedc0 |
checking for TIFFOpen in -ltiff... no
configure: error: "Cannot build without libtiff (does your system require a libtiff-devel package?)"
Bernd, you added spandsp recently, could you have a look ?
Post by Thomas Petazzoni
powerpc | squid-4.2 | NOK | http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751 | ORPH
../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0' is allowed) before ';' token
../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0' is allowed) before ';' token
Not sure. Baruch, you recently bumped the squid package, could you have
a look ?
Post by Thomas Petazzoni
microblazeel | target-finalize | NOK | http://autobuild.buildroot.net/results/068fa36a0be7a2207144cfcc9d595d6099bd9e39 |
xtensa | target-finalize | NOK | http://autobuild.buildroot.net/results/3b17b82658842849cf72d01b6f6a4f735e13a642 |
xtensa | target-finalize | NOK | http://autobuild.buildroot.net/results/c76bf4a1902da001de673c2160e7f68f83072feb |
mips | target-finalize | NOK | http://autobuild.buildroot.net/results/a0f68aba5c02cbf053c0a425667f1393ef71a0e5 |
arc | target-finalize | NOK | http://autobuild.buildroot.net/results/21adc28431f328526d88158e98e84b2fab2e4275 |
mipsel | target-finalize | NOK | http://autobuild.buildroot.net/results/0bf569d8d0ae380bdd1c8b6ddfa111e85670e981 |
powerpc | target-finalize | NOK | http://autobuild.buildroot.net/results/f92fd883386a547d42e0c699f7db859f2918e3f2 |
powerpc | target-finalize | NOK | http://autobuild.buildroot.net/results/ca096daed97a11b9be1618bd284b626527414e88 |
arm | target-finalize | NOK | http://autobuild.buildroot.net/results/8b4ce48f1b612710b8f2bb1b4ca3b203e1ed6293 |
aarch64 | target-finalize | NOK | http://autobuild.buildroot.net/results/797e736dc81d84e63a9293a7b1b62d7d4ae29194 |
arc | target-finalize | NOK | http://autobuild.buildroot.net/results/dd94cc60c4eb5a102b04db52b0ee2c7417c0c2f5 |
x86_64 | target-finalize | NOK | http://autobuild.buildroot.net/results/8329204dc3737635b92c2fdef224992f3c302f0c |
arm | target-finalize | NOK | http://autobuild.buildroot.net/results/5ab016529d2ec177f2865ac184d4a91149a649db |
aarch64_be | target-finalize | NOK | http://autobuild.buildroot.net/results/b8e27bd74c40cbc6f6ed9c5df4f0021af4fda050 |
mips64el | target-finalize | NOK | http://autobuild.buildroot.net/results/a5f6626116e8e721d5f6eb1d0aebf4656b9452f0 |
arm | target-finalize | NOK | http://autobuild.buildroot.net/results/89b5cc38f7b45046417fa20bbd8078646e9c39ef |
aarch64 | target-finalize | NOK | http://autobuild.buildroot.net/results/a28d07fd7999f1505a346598ea62ac3c212db7a2 |
arc | target-finalize | NOK | http://autobuild.buildroot.net/results/c905171b7a2beb768e23c7b834c50df0764500e1 |
I had a look at those 22 (18+4) failures, and all of them are caused either by
pysnmp or psycopg2 issues with Python 3.7.0. pysnmp was fixed today
(https://git.buildroot.org/buildroot/commit/?id=8122a1d85b6cc9f2adcb1243521c04ba4cae0510).
So the only package remaining package to fix is psycopg2.
Asaf, Yegor, Adam, could one of you take care of fixing psycopg2 soon ?
Related to this, I find it a bit annoying that all those issues are
detected at the target-finalize step, since package maintainers are not
properly notified. Should we move the byte-compile step as the end of
each Python package installation, so that if it fails, it fails
earlier, and within the context of that package ? Is the
byte-compilation process smart enough to skip compiling when a .pyc
file already exists and is newer than the matching .py file ? It would
be interesting to do a time comparison between doing per-package
byte-compilation and one global byte-compilation at the end.
Post by Thomas Petazzoni
arc | traceroute-2.1.0 | NOK | http://autobuild.buildroot.net/results/22855418dcb5bca4b6499991bc810b368a0cfcd5 |
make[3]: *** No rule to make target '-lm', needed by 'traceroute'. Stop.
make[3]: *** Waiting for unfinished jobs....
Meh ?
Post by Thomas Petazzoni
powerpc64le | util-linux-2.32.1 | NOK | http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b |
checking for SELINUX... no
configure: error: SELinux selected but libselinux not found or too old
We've been having this one for a while. Could some SELinux person
(Matt ? Adam ?) debug this ?
I can take a look. Before I dig to deep, I'd suggest applying the 2.8
bump (http://patchwork.ozlabs.org/project/buildroot/list/?series=66983).
I've finished runtime testing and it would be good to fix this and
perform my testing on the latest.

Note, this report doesn't have it, but there has been a standing
host-libsemanage 2.7 failure I've been ignoring until the 2.8 is
applied. (http://autobuild.buildroot.net/?reason=host-libsemanage-2.7)

Matt
Fabrice Fontaine
2018-10-10 17:57:58 UTC
Permalink
Dear all,

Le mer. 10 oct. 2018 à 18:28, Matthew Weber <
Post by Matthew Weber
Thomas,
On Wed, Oct 10, 2018 at 10:48 AM Thomas Petazzoni
Post by Thomas Petazzoni
Hello,
Here is an analysis of yesterday build results. Johan, Frank,
Christian, Fabrice, Peter, Matt, Bernd, Giulio, Baruch, you are in Cc
because there are questions/issues for you below. Thanks! :-)
Post by Thomas Petazzoni
master | 187 | 68 | 0 | 255 |
These results are not very good, let's have a look at what's going on,
and try to get everyone to help fixing those issues.
Post by Thomas Petazzoni
arm | boa-0.94.14rc21 | NOK |
http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11
| ORPH
Post by Thomas Petazzoni
(cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
make: unrecognized option '--jobserver-fds=6,7'
This suddenly started happening on September 9, 2018. We have not
bumped boa. I'm not sure what caused this. It fails on different
autobuilder machines. Boa is calling submake with $(MFLAGS), which is
probably the issue, but why did this suddenly started to happen ?
With a minimal configuration with just Boa, I cannot reproduce on my
machine here, neither on my autobuilder where the problem is reported
to occur.
Post by Thomas Petazzoni
i686 | boost-1.68.0 | NOK |
http://autobuild.buildroot.net/results/1ceed7d91627711c12c4866fa6672a02fc6ddc8c
|
Post by Thomas Petazzoni
libboost_chrono shouldn't have been installed: missing select in
boost/Config.in
Can be fixed by https://patchwork.ozlabs.org/patch/960723.
Post by Matthew Weber
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | boost-1.68.0 | NOK |
http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f
|
Post by Thomas Petazzoni
libboost_atomic shouldn't have been installed: missing select in
boost/Config.in
Can be fixed by https://patchwork.ozlabs.org/patch/966309.
It should be noted that this patch has been merged upstream:
https://github.com/boostorg/thread/commit/f7581a366294c6f5381e0371c242af327c6da655
Post by Matthew Weber
Post by Thomas Petazzoni
Fabrice, these two are for you :)
Post by Thomas Petazzoni
mips64el | brltty-5.6 | NOK |
http://autobuild.buildroot.net/results/7187e560e66f2bd6073b5510e2782ebdaccfb4a9
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | brltty-5.6 | NOK |
http://autobuild.buildroot.net/results/5f8e8b8517fda50a2e98a456933260f08054356d
|
Post by Thomas Petazzoni
Those should be fixed by
https://git.buildroot.org/buildroot/commit/?id=9143c217213542574586c0e6a9f003e822633917
.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
aarch64 | collectd-5.7.1 | NOK |
http://autobuild.buildroot.net/results/24a280d6233b3284edd44c4528d8799c6894c11a
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
sh4 | collectd-5.7.1 | NOK |
http://autobuild.buildroot.net/results/63a4f980d7cdb4b0823840f747589803fcd0d69f
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arc | collectd-5.7.1 | NOK |
http://autobuild.buildroot.net/results/1a6f2fcf1a88ecc5b598dd11c5914dcacf0e1e6b
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | collectd-5.7.1 | NOK |
http://autobuild.buildroot.net/results/b0829bc3343d6dc3065078e94896725b1c808bc1
| ORPH
Post by Thomas Petazzoni
Fixed by
https://git.buildroot.org/buildroot/commit/package/collectd?id=d65ea85fddaf64a7762f958d1ce9fb33997648d3
Post by Thomas Petazzoni
Post by Thomas Petazzoni
x86_64 | docker-containerd-v1.1.3 | NOK |
http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
x86_64 | docker-containerd-v1.1.3 | NOK |
http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
x86_64 | docker-containerd-v1.1.3 | NOK |
http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c
|
running
/home/naourr/work/instance-3/output/host/bin/x86_64-amd-linux-gnu-gcc
failed: exit status 1
Post by Thomas Petazzoni
/tmp/go-build283204336/b001/exe/a.out: final close failed: Invalid
operation
Post by Thomas Petazzoni
Christian, what is happening here? Could you have a look?
Post by Thomas Petazzoni
x86_64 | erlang-21.0 | NOK |
http://autobuild.buildroot.net/results/fc633f80c7c36a90e641487f5a888fbb767c2a54
|
Post by Thomas Petazzoni
zlib/zutil.h:172:39: error: "_LFS64_LARGEFILE" is not defined
[-Werror=undef]
Post by Thomas Petazzoni
(!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
Seems like a musl/erlang issue. Johan, Frank, could you have a look ?
Post by Thomas Petazzoni
arc | glibc-legal-info | NOK |
http://autobuild.buildroot.net/results/64c70d82c857c272df171ae6783629c1ba92d812
| ORPH
Post by Thomas Petazzoni
Fixed by
https://git.buildroot.org/buildroot/commit/?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e
.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | gpsd-3.18 | NOK |
http://autobuild.buildroot.net/results/c00d22a6dcadb82a19afab6eacea654d3c41b4c5
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc | gpsd-3.18 | NOK |
http://autobuild.buildroot.net/results/18599ea12a35b9715a67c1f4e5c4e56906235c94
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | gpsd-3.18 | NOK |
http://autobuild.buildroot.net/results/a13a5d852c83cd1fc9f2d1fc2b7302db515278b8
| ORPH
Post by Thomas Petazzoni
Fixed by
https://git.buildroot.org/buildroot/commit/package/gpsd?id=ae2a91322aeaa72d6f5354312056d16dc275470d
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | gst-plugins-bad-0.10.23 | NOK |
http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5
| ORPH
Post by Thomas Petazzoni
gstspanplc.c:223:21: error: dereferencing pointer to incomplete type
'plc_state_t {aka struct plc_state_s}'
Post by Thomas Petazzoni
if (plc->plc_state->missing_samples != 0)
Peter (Seiderer) ?
Post by Thomas Petazzoni
arm | host-go-1.11 | NOK |
http://autobuild.buildroot.net/results/8d3af6f00bf34737faabc21bdccf7d025462fec7
|
Post by Thomas Petazzoni
fatal error: unexpected signal during runtime execution
[signal SIGBUS: bus error code=0x2 addr=0xc000800010 pc=0x42098d]
This particular issue seems to happen only on Matt autobuilder. Matt,
can you check if you can reproduce it reliably ?
I'll take a look.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc | libmpeg2-0.5.1 | NOK |
http://autobuild.buildroot.net/results/69f52854b222b5be1a981b96a804098fec5a849b
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc | libmpeg2-0.5.1 | NOK |
http://autobuild.buildroot.net/results/eb8dc1e67eae123a823fadc17ca7611c2cc7f621
| ORPH
Post by Thomas Petazzoni
motion_comp_altivec.c:48:12: internal compiler error: Segmentation fault
return vec_ld (A, (uint8_t *)B);
Bernd, could you have a look at this PowerPC/Altivec issue ?
Post by Thomas Petazzoni
arm | luvi-v2.8.0 | NOK |
http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886
|
Post by Thomas Petazzoni
luvi 2.8.0 fails to build. Bernd, you bumped this package, and Jörg
suggested to revert the bump. Could you discuss this, and provide a fix?
Post by Thomas Petazzoni
aarch64 | Makefile:709: target-finalize | NOK |
http://autobuild.buildroot.net/results/dcbbae0180bc597c58fc694c3006b623633aab7f
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
aarch64 | Makefile:709: target-finalize | NOK |
http://autobuild.buildroot.net/results/cef7e38fbd4de65d1830f681a497bc007a897502
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | Makefile:709: target-finalize | NOK |
http://autobuild.buildroot.net/results/62143510a7ede7d92f55e908306bc367586c2748
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
sparc64 | Makefile:709: target-finalize | NOK |
http://autobuild.buildroot.net/results/d0c1aa394745ba48d832cc77c23721ca6b453d23
|
Post by Thomas Petazzoni
See below "target-finalize"
Post by Thomas Petazzoni
m68k | minizip-2.5.3 | NOK |
http://autobuild.buildroot.net/results/78b8eb0f9f7f2963f0056834054f16e764bc3106
|
undefined reference to `__register_atfork'
Post by Thomas Petazzoni
collect2: error: ld returned 1 exit status
I guess it would be fixed by http://patchwork.ozlabs.org/patch/978465/.
Someone needs to review this.
Post by Thomas Petazzoni
powerpc | motion-release-4.1.1 | NOK |
http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5
|
undefined reference to `drmGetVersion'
undefined reference to `drmFreeVersion'
Post by Thomas Petazzoni
Giulio, I believe you worked on this static linking problem between
ffmpeg and libdrm. What is the status of this ?
Post by Thomas Petazzoni
arm | netsnmp-5.8 | NOK |
http://autobuild.buildroot.net/results/9f02e0f09ae2d2a66a8d33d73f1bdd45ea8b0f16
| ORPH
Post by Thomas Petazzoni
configure: error: The DTLS based transports require the libssl library
from OpenSSL to be available and support DTLS
Post by Thomas Petazzoni
Bernd, you did the last version bump of netsnmp, could you have a look ?
Post by Thomas Petazzoni
arm | open-plc-utils-1be781d1ea81... | NOK |
http://autobuild.buildroot.net/results/67bc5e7ac8ae1c49c035b022a394d2f746705cf2
|
Post by Thomas Petazzoni
I assume this would be fixed by
http://patchwork.ozlabs.org/patch/981495/.
Post by Thomas Petazzoni
arc | package/glibc/glibc.mk:143:... | NOK |
http://autobuild.buildroot.net/results/4a1ddb5c0afb1e80ac769d36cb720372f7bb5457
|
Post by Thomas Petazzoni
Fixed by
https://git.buildroot.org/buildroot/commit/package/glibc?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e
.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | php-7.2.10 | NOK |
http://autobuild.buildroot.net/results/7b7e25bfd269f7c252d15ab4e9f1b68348823478
| ORPH
Post by Thomas Petazzoni
multiple definition of
`icu_60::MessageFormatAdapter::getArgTypeList(icu_60::MessageFormat const&,
int&)'
Post by Thomas Petazzoni
Long standing issue. Anyone brave enough to investigate ?
Post by Thomas Petazzoni
microblazeel | ptpd2-ptpd-2.3.1 | NOK |
http://autobuild.buildroot.net/results/1c00bfa77c38f0aad7643344b16d8f401c9b927a
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | ptpd2-ptpd-2.3.1 | NOK |
http://autobuild.buildroot.net/results/298fda61ab5a192c235027e1b4c57aba4e6b8b37
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | ptpd2-ptpd-2.3.1 | NOK |
http://autobuild.buildroot.net/results/8fe8061cb27cbab8f02e6dfb0a870d76be3f7f3e
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
xtensa | ptpd2-ptpd-2.3.1 | NOK |
http://autobuild.buildroot.net/results/80b014e965b088e6767af671d39657b415f82453
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mipsel | ptpd2-ptpd-2.3.1 | NOK |
http://autobuild.buildroot.net/results/40f1090a0eb720d4cce2715bca51823213efb9f9
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | ptpd2-ptpd-2.3.1 | NOK |
http://autobuild.buildroot.net/results/55933c2c4ecf8a84b283c93adf0c2ed8a4f03301
| ORPH
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | ptpd2-ptpd-2.3.1 | NOK |
http://autobuild.buildroot.net/results/08d40b95945ed0e61805b07446b5eb5731f23198
| ORPH
Post by Thomas Petazzoni
Should be fixed by http://patchwork.ozlabs.org/patch/964746/. I haven't
had the chance to review it.
Post by Thomas Petazzoni
aarch64_be | qt5base-5.11.2 | NOK |
http://autobuild.buildroot.net/results/aeddb85c0262cdc23019c72e1c390d3885cb4ae4
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
aarch64_be | qt5base-5.11.2 | NOK |
http://autobuild.buildroot.net/results/5bec7d7f14befa3a03f902ef90cc2c6589943ec2
|
internal error in update_erratum_insn, at
/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64_be-linux-gnu/snapshots/binutils-gdb.git~users~linaro~binutils-2_28-branch/gold/aarch64.cc:998
Post by Thomas Petazzoni
Compiler bug it seems. Anyone to have a look ?
Post by Thomas Petazzoni
mipsel | qt5webkit-5.9.1 | NOK |
http://autobuild.buildroot.net/results/7aca204c7fd486def6306412b0a6e0bfb8234786
|
mips32r6 (mips32r6) `movz $v0,$t8,$t7'
mips32r6 (mips32r6) `movz $v1,$t8,$t7'
mips32r6 (mips32r6) `movz $t2,$t8,$t7'
Post by Thomas Petazzoni
We should disable qt5webkit on mips32r6. Peter ?
Post by Thomas Petazzoni
arm | qt5webkit-5.9.1 | NOK |
http://autobuild.buildroot.net/results/b8ae1b94891206746815fa85fafabfbd6bed8c74
|
In function
undefined reference to `leveldb::NewMemEnv(leveldb::Env*)'
Post by Thomas Petazzoni
Ah, yes, we have a patch fixing that in patchwork. I don't like it a
lot, but I guess that's the only option.
Post by Thomas Petazzoni
arm | spandsp-20180108 | NOK |
http://autobuild.buildroot.net/results/05885325ec274cb9860d423c57eed5e7063aedc0
|
Post by Thomas Petazzoni
checking for TIFFOpen in -ltiff... no
configure: error: "Cannot build without libtiff (does your system
require a libtiff-devel package?)"
Post by Thomas Petazzoni
Bernd, you added spandsp recently, could you have a look ?
Post by Thomas Petazzoni
powerpc | squid-4.2 | NOK |
http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751
| ORPH
Post by Thomas Petazzoni
../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0'
is allowed) before ';' token
Post by Thomas Petazzoni
../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0'
is allowed) before ';' token
Post by Thomas Petazzoni
Not sure. Baruch, you recently bumped the squid package, could you have
a look ?
Post by Thomas Petazzoni
microblazeel | target-finalize | NOK |
http://autobuild.buildroot.net/results/068fa36a0be7a2207144cfcc9d595d6099bd9e39
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
xtensa | target-finalize | NOK |
http://autobuild.buildroot.net/results/3b17b82658842849cf72d01b6f6a4f735e13a642
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
xtensa | target-finalize | NOK |
http://autobuild.buildroot.net/results/c76bf4a1902da001de673c2160e7f68f83072feb
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips | target-finalize | NOK |
http://autobuild.buildroot.net/results/a0f68aba5c02cbf053c0a425667f1393ef71a0e5
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arc | target-finalize | NOK |
http://autobuild.buildroot.net/results/21adc28431f328526d88158e98e84b2fab2e4275
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mipsel | target-finalize | NOK |
http://autobuild.buildroot.net/results/0bf569d8d0ae380bdd1c8b6ddfa111e85670e981
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc | target-finalize | NOK |
http://autobuild.buildroot.net/results/f92fd883386a547d42e0c699f7db859f2918e3f2
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc | target-finalize | NOK |
http://autobuild.buildroot.net/results/ca096daed97a11b9be1618bd284b626527414e88
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | target-finalize | NOK |
http://autobuild.buildroot.net/results/8b4ce48f1b612710b8f2bb1b4ca3b203e1ed6293
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
aarch64 | target-finalize | NOK |
http://autobuild.buildroot.net/results/797e736dc81d84e63a9293a7b1b62d7d4ae29194
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arc | target-finalize | NOK |
http://autobuild.buildroot.net/results/dd94cc60c4eb5a102b04db52b0ee2c7417c0c2f5
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
x86_64 | target-finalize | NOK |
http://autobuild.buildroot.net/results/8329204dc3737635b92c2fdef224992f3c302f0c
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | target-finalize | NOK |
http://autobuild.buildroot.net/results/5ab016529d2ec177f2865ac184d4a91149a649db
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
aarch64_be | target-finalize | NOK |
http://autobuild.buildroot.net/results/b8e27bd74c40cbc6f6ed9c5df4f0021af4fda050
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | target-finalize | NOK |
http://autobuild.buildroot.net/results/a5f6626116e8e721d5f6eb1d0aebf4656b9452f0
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | target-finalize | NOK |
http://autobuild.buildroot.net/results/89b5cc38f7b45046417fa20bbd8078646e9c39ef
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
aarch64 | target-finalize | NOK |
http://autobuild.buildroot.net/results/a28d07fd7999f1505a346598ea62ac3c212db7a2
|
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arc | target-finalize | NOK |
http://autobuild.buildroot.net/results/c905171b7a2beb768e23c7b834c50df0764500e1
|
Post by Thomas Petazzoni
I had a look at those 22 (18+4) failures, and all of them are caused
either by
Post by Thomas Petazzoni
pysnmp or psycopg2 issues with Python 3.7.0. pysnmp was fixed today
(
https://git.buildroot.org/buildroot/commit/?id=8122a1d85b6cc9f2adcb1243521c04ba4cae0510
).
Post by Thomas Petazzoni
So the only package remaining package to fix is psycopg2.
Asaf, Yegor, Adam, could one of you take care of fixing psycopg2 soon ?
Related to this, I find it a bit annoying that all those issues are
detected at the target-finalize step, since package maintainers are not
properly notified. Should we move the byte-compile step as the end of
each Python package installation, so that if it fails, it fails
earlier, and within the context of that package ? Is the
byte-compilation process smart enough to skip compiling when a .pyc
file already exists and is newer than the matching .py file ? It would
be interesting to do a time comparison between doing per-package
byte-compilation and one global byte-compilation at the end.
Post by Thomas Petazzoni
arc | traceroute-2.1.0 | NOK |
http://autobuild.buildroot.net/results/22855418dcb5bca4b6499991bc810b368a0cfcd5
|
Post by Thomas Petazzoni
make[3]: *** No rule to make target '-lm', needed by 'traceroute'. Stop.
make[3]: *** Waiting for unfinished jobs....
Meh ?
Post by Thomas Petazzoni
powerpc64le | util-linux-2.32.1 | NOK |
http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b
|
Post by Thomas Petazzoni
checking for SELINUX... no
configure: error: SELinux selected but libselinux not found or too old
We've been having this one for a while. Could some SELinux person
(Matt ? Adam ?) debug this ?
I can take a look.
I worked on this one without finding how to fix it.
Here is my finding so I hope it could help you.
It seems that the issue is that libselinux is really not built before
util-linux. Indeed, we can see in
http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b/build-time.log,
that only libsepol is built.
I don't know why libselinux is not built perhaps because libselinux,
libsepol and all other selinux packages share the same archive (i.e.
https://raw.githubusercontent.com/wiki/SELinuxProject/selinux/files/releases/20180524
)?
Post by Matthew Weber
Before I dig to deep, I'd suggest applying the 2.8
bump (http://patchwork.ozlabs.org/project/buildroot/list/?series=66983).
I've finished runtime testing and it would be good to fix this and
perform my testing on the latest.
Note, this report doesn't have it, but there has been a standing
host-libsemanage 2.7 failure I've been ignoring until the 2.8 is
applied. (http://autobuild.buildroot.net/?reason=host-libsemanage-2.7)
Matt
Best Regards,

Fabrice
Thomas Petazzoni
2018-10-10 19:14:19 UTC
Permalink
Hello Fabrice,
Post by Fabrice Fontaine
Post by Thomas Petazzoni
Post by Thomas Petazzoni
libboost_chrono shouldn't have been installed: missing select in
boost/Config.in
Can be fixed by https://patchwork.ozlabs.org/patch/960723.
OK.
Post by Fabrice Fontaine
Post by Thomas Petazzoni
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | boost-1.68.0 | NOK |
http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f
|
Post by Thomas Petazzoni
libboost_atomic shouldn't have been installed: missing select in
boost/Config.in
Can be fixed by https://patchwork.ozlabs.org/patch/966309.
https://github.com/boostorg/thread/commit/f7581a366294c6f5381e0371c242af327c6da655
OK, I was still not entirely convinced by this one, but if it has been
merged upstream, so be it :-)
Post by Fabrice Fontaine
Post by Thomas Petazzoni
Post by Thomas Petazzoni
checking for SELINUX... no
configure: error: SELinux selected but libselinux not found or too old
We've been having this one for a while. Could some SELinux person
(Matt ? Adam ?) debug this ?
I can take a look.
I worked on this one without finding how to fix it.
Here is my finding so I hope it could help you.
It seems that the issue is that libselinux is really not built before
util-linux. Indeed, we can see in
http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b/build-time.log,
that only libsepol is built.
Aah, thanks for this hint. Then it becomes clear what the problem is:
we're facing the util-linux -> python3 -> util-linux circular
dependency. If you look at all the failures at
http://autobuild.buildroot.net/?reason=util-linux-2.32.1, all of them
have BR2_PACKAGE_PYTHON3_UUID=y, and this creates a python3 ->
util-linux dependency. When there is a circular dependency, make
automatically drops a dependency to avoid the circular loop.

We need to resolve this util-linux -> python3 -> util-linux circular
dependency. Arnout suggested that python3 can provide uuid
functionality without libuuid, and I did some tests about this, which I
reported on the mailing list at
http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html.
See the whole thread that starts at
http://lists.busybox.net/pipermail/buildroot/2018-September/229746.html.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Matthew Weber
2018-10-10 21:25:41 UTC
Permalink
Adam,

On Wed, Oct 10, 2018 at 2:14 PM Thomas Petazzoni
Post by Thomas Petazzoni
Hello Fabrice,
Post by Fabrice Fontaine
Post by Thomas Petazzoni
Post by Thomas Petazzoni
libboost_chrono shouldn't have been installed: missing select in
boost/Config.in
Can be fixed by https://patchwork.ozlabs.org/patch/960723.
OK.
Post by Fabrice Fontaine
Post by Thomas Petazzoni
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | boost-1.68.0 | NOK |
http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f
|
Post by Thomas Petazzoni
libboost_atomic shouldn't have been installed: missing select in
boost/Config.in
Can be fixed by https://patchwork.ozlabs.org/patch/966309.
https://github.com/boostorg/thread/commit/f7581a366294c6f5381e0371c242af327c6da655
OK, I was still not entirely convinced by this one, but if it has been
merged upstream, so be it :-)
Post by Fabrice Fontaine
Post by Thomas Petazzoni
Post by Thomas Petazzoni
checking for SELINUX... no
configure: error: SELinux selected but libselinux not found or too old
We've been having this one for a while. Could some SELinux person
(Matt ? Adam ?) debug this ?
I can take a look.
I worked on this one without finding how to fix it.
Here is my finding so I hope it could help you.
It seems that the issue is that libselinux is really not built before
util-linux. Indeed, we can see in
http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b/build-time.log,
that only libsepol is built.
we're facing the util-linux -> python3 -> util-linux circular
dependency. If you look at all the failures at
http://autobuild.buildroot.net/?reason=util-linux-2.32.1, all of them
have BR2_PACKAGE_PYTHON3_UUID=y, and this creates a python3 ->
util-linux dependency. When there is a circular dependency, make
automatically drops a dependency to avoid the circular loop.
We need to resolve this util-linux -> python3 -> util-linux circular
dependency. Arnout suggested that python3 can provide uuid
functionality without libuuid, and I did some tests about this, which I
reported on the mailing list at
http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html.
See the whole thread that starts at
http://lists.busybox.net/pipermail/buildroot/2018-September/229746.html.
Adam, did you have something in the works for this one? I seem to
remember some discussion on the one "whole" thread above related to
breaking the dependency. I'd make the change but I don't have a valid
test case.

Matt
Thomas Petazzoni
2018-10-11 06:50:17 UTC
Permalink
Hello,
Post by Matthew Weber
Adam, did you have something in the works for this one? I seem to
remember some discussion on the one "whole" thread above related to
breaking the dependency. I'd make the change but I don't have a valid
test case.
Well, Arnout statement was that the build dependency is not necessary
because python3 can dlopen() at runtime the libuuid.so library. Indeed
the code in Python3 is here to do that, but as I explained in
http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
it doesn't seem to work, at least in the Buildroot context.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Matthew Weber
2018-10-11 13:35:05 UTC
Permalink
Thomas,

On Thu, Oct 11, 2018 at 1:50 AM Thomas Petazzoni
Post by Thomas Petazzoni
Hello,
Post by Matthew Weber
Adam, did you have something in the works for this one? I seem to
remember some discussion on the one "whole" thread above related to
breaking the dependency. I'd make the change but I don't have a valid
test case.
Well, Arnout statement was that the build dependency is not necessary
because python3 can dlopen() at runtime the libuuid.so library. Indeed
the code in Python3 is here to do that, but as I explained in
http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
it doesn't seem to work, at least in the Buildroot context.
I reached out to Adam, this dependency on uuid was added as part of
the python upgrade and not for a specific product need. I'll see if I
can reproduce the python pkg build failure for its uuid support (Adam
mentioned this is why he added the buildroot dependency on util-linux)
. Then depending on that, submit a patch to disable uuid support in
python and remove the dependency we currently have on the util linux
uuid lib.

Matt
Matthew Weber
2018-10-12 03:57:31 UTC
Permalink
Thomas,


On Thu, Oct 11, 2018 at 1:50 AM Thomas Petazzoni
Post by Thomas Petazzoni
Hello,
Post by Matthew Weber
Adam, did you have something in the works for this one? I seem to
remember some discussion on the one "whole" thread above related to
breaking the dependency. I'd make the change but I don't have a valid
test case.
Well, Arnout statement was that the build dependency is not necessary
because python3 can dlopen() at runtime the libuuid.so library. Indeed
the code in Python3 is here to do that, but as I explained in
http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
it doesn't seem to work, at least in the Buildroot context.
I dug through this a bit more and found that the c library is
providing the implementation for uuid.uuid1() when uuid_generate_time*
is probed for in libraries using ctypes. I believe that the
util-linux libuuid would come into play if the extension module
approach worked (all the configure tests currently fail which disable
use of python3-3.7.0/Modules/_uuidmodule.c).

I believe the right fix for now is cleaning up the current approach
(removing the ability to enable/disable uuid and the util-linux
dependency) as it looks like python can support uuid by default with
the current glibc. My guess is we'll see build failures with the
other std libraries....

Matt
Matthew Weber
2018-10-12 14:16:05 UTC
Permalink
Thomas,

On Thu, Oct 11, 2018 at 10:57 PM Matthew Weber
Post by Matthew Weber
Thomas,
On Thu, Oct 11, 2018 at 1:50 AM Thomas Petazzoni
Post by Thomas Petazzoni
Hello,
Post by Matthew Weber
Adam, did you have something in the works for this one? I seem to
remember some discussion on the one "whole" thread above related to
breaking the dependency. I'd make the change but I don't have a valid
test case.
Well, Arnout statement was that the build dependency is not necessary
because python3 can dlopen() at runtime the libuuid.so library. Indeed
the code in Python3 is here to do that, but as I explained in
http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
it doesn't seem to work, at least in the Buildroot context.
I dug through this a bit more and found that the c library is
providing the implementation for uuid.uuid1() when uuid_generate_time*
is probed for in libraries using ctypes. I believe that the
util-linux libuuid would come into play if the extension module
approach worked (all the configure tests currently fail which disable
use of python3-3.7.0/Modules/_uuidmodule.c).
I believe the right fix for now is cleaning up the current approach
(removing the ability to enable/disable uuid and the util-linux
dependency) as it looks like python can support uuid by default with
the current glibc. My guess is we'll see build failures with the
other std libraries....
http://patchwork.ozlabs.org/patch/983070/
Matthew Weber
2018-10-20 14:10:48 UTC
Permalink
Thomas, Arnout,
On Fri, Oct 12, 2018 at 3:16 PM Matthew Weber
Post by Matthew Weber
Thomas,
On Thu, Oct 11, 2018 at 10:57 PM Matthew Weber
Post by Matthew Weber
Thomas,
On Thu, Oct 11, 2018 at 1:50 AM Thomas Petazzoni
Post by Thomas Petazzoni
Hello,
Post by Matthew Weber
Adam, did you have something in the works for this one? I seem to
remember some discussion on the one "whole" thread above related to
breaking the dependency. I'd make the change but I don't have a valid
test case.
Well, Arnout statement was that the build dependency is not necessary
because python3 can dlopen() at runtime the libuuid.so library. Indeed
the code in Python3 is here to do that, but as I explained in
http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
it doesn't seem to work, at least in the Buildroot context.
I dug through this a bit more and found that the c library is
providing the implementation for uuid.uuid1() when uuid_generate_time*
is probed for in libraries using ctypes. I believe that the
util-linux libuuid would come into play if the extension module
approach worked (all the configure tests currently fail which disable
use of python3-3.7.0/Modules/_uuidmodule.c).
I believe the right fix for now is cleaning up the current approach
(removing the ability to enable/disable uuid and the util-linux
dependency) as it looks like python can support uuid by default with
the current glibc. My guess is we'll see build failures with the
other std libraries....
http://patchwork.ozlabs.org/patch/983070/
Here's v3 Arnout and I reviewed this morning. v2 -> v3 improved the
commit description
https://patchwork.ozlabs.org/patch/987192/
Thomas Petazzoni
2018-10-10 19:05:03 UTC
Permalink
Hello,
Post by Matthew Weber
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc64le | util-linux-2.32.1 | NOK | http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b |
checking for SELINUX... no
configure: error: SELinux selected but libselinux not found or too old
We've been having this one for a while. Could some SELinux person
(Matt ? Adam ?) debug this ?
I can take a look. Before I dig to deep, I'd suggest applying the 2.8
bump (http://patchwork.ozlabs.org/project/buildroot/list/?series=66983).
I've finished runtime testing and it would be good to fix this and
perform my testing on the latest.
I will have a look at this series and merge it. I was waiting for you
to test it, but it's indeed done since September 28, so it's time to
merge the series.

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Matthew Weber
2018-10-12 16:00:24 UTC
Permalink
Thomas,

On Wed, Oct 10, 2018 at 11:28 AM Matthew Weber
Post by Matthew Weber
Thomas,
On Wed, Oct 10, 2018 at 10:48 AM Thomas Petazzoni
Post by Thomas Petazzoni
Hello,
Here is an analysis of yesterday build results. Johan, Frank,
Christian, Fabrice, Peter, Matt, Bernd, Giulio, Baruch, you are in Cc
because there are questions/issues for you below. Thanks! :-)
Post by Thomas Petazzoni
master | 187 | 68 | 0 | 255 |
These results are not very good, let's have a look at what's going on,
and try to get everyone to help fixing those issues.
Post by Thomas Petazzoni
arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
(cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
make: unrecognized option '--jobserver-fds=6,7'
This suddenly started happening on September 9, 2018. We have not
bumped boa. I'm not sure what caused this. It fails on different
autobuilder machines. Boa is calling submake with $(MFLAGS), which is
probably the issue, but why did this suddenly started to happen ?
With a minimal configuration with just Boa, I cannot reproduce on my
machine here, neither on my autobuilder where the problem is reported
to occur.
Post by Thomas Petazzoni
i686 | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/1ceed7d91627711c12c4866fa6672a02fc6ddc8c |
libboost_chrono shouldn't have been installed: missing select in boost/Config.in
Post by Thomas Petazzoni
arm | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f |
libboost_atomic shouldn't have been installed: missing select in boost/Config.in
Fabrice, these two are for you :)
Post by Thomas Petazzoni
mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/7187e560e66f2bd6073b5510e2782ebdaccfb4a9 |
mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/5f8e8b8517fda50a2e98a456933260f08054356d |
Those should be fixed by
https://git.buildroot.org/buildroot/commit/?id=9143c217213542574586c0e6a9f003e822633917.
Post by Thomas Petazzoni
aarch64 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/24a280d6233b3284edd44c4528d8799c6894c11a | ORPH
sh4 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/63a4f980d7cdb4b0823840f747589803fcd0d69f | ORPH
arc | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/1a6f2fcf1a88ecc5b598dd11c5914dcacf0e1e6b | ORPH
arm | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/b0829bc3343d6dc3065078e94896725b1c808bc1 | ORPH
Fixed by
https://git.buildroot.org/buildroot/commit/package/collectd?id=d65ea85fddaf64a7762f958d1ce9fb33997648d3
Post by Thomas Petazzoni
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b |
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da |
x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c |
/home/naourr/work/instance-3/output/host/lib/go/pkg/tool/linux_amd64/link: running /home/naourr/work/instance-3/output/host/bin/x86_64-amd-linux-gnu-gcc failed: exit status 1
/tmp/go-build283204336/b001/exe/a.out: final close failed: Invalid operation
Christian, what is happening here? Could you have a look?
Post by Thomas Petazzoni
x86_64 | erlang-21.0 | NOK | http://autobuild.buildroot.net/results/fc633f80c7c36a90e641487f5a888fbb767c2a54 |
zlib/zutil.h:172:39: error: "_LFS64_LARGEFILE" is not defined [-Werror=undef]
(!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
Seems like a musl/erlang issue. Johan, Frank, could you have a look ?
Post by Thomas Petazzoni
arc | glibc-legal-info | NOK | http://autobuild.buildroot.net/results/64c70d82c857c272df171ae6783629c1ba92d812 | ORPH
Fixed by
https://git.buildroot.org/buildroot/commit/?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e.
Post by Thomas Petazzoni
mips64el | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/c00d22a6dcadb82a19afab6eacea654d3c41b4c5 | ORPH
powerpc | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/18599ea12a35b9715a67c1f4e5c4e56906235c94 | ORPH
arm | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/a13a5d852c83cd1fc9f2d1fc2b7302db515278b8 | ORPH
Fixed by https://git.buildroot.org/buildroot/commit/package/gpsd?id=ae2a91322aeaa72d6f5354312056d16dc275470d
Post by Thomas Petazzoni
mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
if (plc->plc_state->missing_samples != 0)
Peter (Seiderer) ?
Post by Thomas Petazzoni
arm | host-go-1.11 | NOK | http://autobuild.buildroot.net/results/8d3af6f00bf34737faabc21bdccf7d025462fec7 |
fatal error: unexpected signal during runtime execution
[signal SIGBUS: bus error code=0x2 addr=0xc000800010 pc=0x42098d]
This particular issue seems to happen only on Matt autobuilder. Matt,
can you check if you can reproduce it reliably ?
Looks like known issue with kernel version 3.13. I'll see what I can
do about upgrading the kernel version or locally blacklist GO for now.

I've opened a new ticket to help them tie-off a theory they had about
the 3.13 that this confirms.
https://github.com/golang/go/issues/28180

Matt
Arnout Vandecappelle
2018-10-10 21:30:39 UTC
Permalink
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
if (plc->plc_state->missing_samples != 0)
Perhaps it's time to retire gstreamer-0.10? Is anybody still using it?

Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
Thomas Petazzoni
2018-10-11 06:46:05 UTC
Permalink
Hello,
Post by Arnout Vandecappelle
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
if (plc->plc_state->missing_samples != 0)
Perhaps it's time to retire gstreamer-0.10? Is anybody still using it?
I am certainly OK to retire gstreamer-0.10. Could someone send a patch
series doing this ?

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Peter Korsgaard
2018-10-11 09:21:40 UTC
Permalink
Post by Arnout Vandecappelle
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
if (plc->plc_state->missing_samples != 0)
Perhaps it's time to retire gstreamer-0.10? Is anybody still using it?
Agreed, 1.0 is from 2012 and 0.10.x is no longer maintained upstream.
--
Bye, Peter Korsgaard
Arnout Vandecappelle
2018-10-11 21:32:34 UTC
Permalink
Post by Peter Korsgaard
Post by Arnout Vandecappelle
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
if (plc->plc_state->missing_samples != 0)
Perhaps it's time to retire gstreamer-0.10? Is anybody still using it?
Agreed, 1.0 is from 2012 and 0.10.x is no longer maintained upstream.
Note that qt4, nvidia-tegra23 and classpath only support GST 0.10. Those were
the only ones I could find. Of these, only qt4 is still a bit relevant I think.

Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
Arnout Vandecappelle
2018-10-10 21:35:55 UTC
Permalink
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | luvi-v2.8.0 | NOK | http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886 |
luvi 2.8.0 fails to build. Bernd, you bumped this package, and Jörg
suggested to revert the bump. Could you discuss this, and provide a fix?
I think luv is missing a dependency on lua-compat53.

Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
Jörg Krause
2018-10-12 06:54:18 UTC
Permalink
Hi,
Post by Arnout Vandecappelle
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | luvi-v2.8.0 | NOK | http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886 |
luvi 2.8.0 fails to build. Bernd, you bumped this package, and Jörg
suggested to revert the bump. Could you discuss this, and provide a fix?
I think luv is missing a dependency on lua-compat53.
That's right! Unfortunately, it does not fix the build issue for luvi
as lua-compat53 does not install the required header file c-api/compat-
5.3.h at all.

So, lua-compat53 needs to be fixed first to install the header file and
luv needs an optional dependency on lua-compat53 if
!BR2_PACKAGE_LUA_5_3.

Best regards,
Jörg Krause
Arnout Vandecappelle
2018-10-10 21:54:51 UTC
Permalink
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | php-7.2.10 | NOK | http://autobuild.buildroot.net/results/7b7e25bfd269f7c252d15ab4e9f1b68348823478 | ORPH
multiple definition of `icu_60::MessageFormatAdapter::getArgTypeList(icu_60::MessageFormat const&, int&)'
Long standing issue. Anyone brave enough to investigate ?
Maybe just make php !STATIC?

Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
Christian Stewart
2018-10-10 21:52:50 UTC
Permalink
Hi Thomas,

On Wed, Oct 10, 2018 at 8:48 AM Thomas Petazzoni <
Post by Thomas Petazzoni
Post by Thomas Petazzoni
x86_64 | docker-containerd-v1.1.3 | NOK |
http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b
|
Post by Thomas Petazzoni
x86_64 | docker-containerd-v1.1.3 | NOK |
http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da
|
Post by Thomas Petazzoni
x86_64 | docker-containerd-v1.1.3 | NOK |
http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c
|
running
/home/naourr/work/instance-3/output/host/bin/x86_64-amd-linux-gnu-gcc
failed: exit status 1
/tmp/go-build283204336/b001/exe/a.out: final close failed: Invalid operation
Christian, what is happening here? Could you have a look?
Geoff Levand and I started having a look at this breakage some time ago but
did not find an immediate fix. It's a very obscure error, but I did manage
to find some non-go references:

- https://lists.gnu.org/archive/html/bug-binutils/2016-04/msg00221.html
- https://sourceware.org/bugzilla/show_bug.cgi?id=20006
- http://lists.busybox.net/pipermail/buildroot/2017-August/200570.html

Buildroot Ruby bug # 20006 seems similar.

This is what we have so far on fixing this.

Best,
~ Christian
Baruch Siach
2018-10-11 04:43:32 UTC
Permalink
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
(cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
make: unrecognized option '--jobserver-fds=6,7'
This suddenly started happening on September 9, 2018. We have not
bumped boa. I'm not sure what caused this. It fails on different
autobuilder machines. Boa is calling submake with $(MFLAGS), which is
probably the issue, but why did this suddenly started to happen ?
With a minimal configuration with just Boa, I cannot reproduce on my
machine here, neither on my autobuilder where the problem is reported
to occur.
I guess it is related to commit 05167a9ffa (package/make: add host
variant) which was applied on September 8, 23:36. Build seems to fail
only on hosts with make older than 4.0, so the host-make build is
triggered.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc | squid-4.2 | NOK | http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751 | ORPH
../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0' is allowed) before ';' token
../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0' is allowed) before ';' token
Not sure. Baruch, you recently bumped the squid package, could you have
a look ?
This failure is from before my patch bumping squid to 4.3 (commit
419c47a2135). But I believe we'll see the same failure with 4.3.

The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
only gcc 4.7 toolchain?

This is the failing code:

typedef double hbase_f(double);

class StatHist
{
...
hbase_f *val_in = nullptr; /* e.g., log() for log-based histogram */
hbase_f *val_out = nullptr; /* e.g., exp() for log based histogram */
}

For some reason this version of gcc considers val_in/val_out as
methods. But "fixing" the problem by changing the assignment to '= 0'
makes gcc segfault, not even ICE. So I think this is a compiler
bug. Should squid depend on gcc >= 4.8?

baruch

--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- ***@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Thomas Petazzoni
2018-10-11 06:53:57 UTC
Permalink
Hello,
Post by Baruch Siach
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
(cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
make: unrecognized option '--jobserver-fds=6,7'
This suddenly started happening on September 9, 2018. We have not
bumped boa. I'm not sure what caused this. It fails on different
autobuilder machines. Boa is calling submake with $(MFLAGS), which is
probably the issue, but why did this suddenly started to happen ?
With a minimal configuration with just Boa, I cannot reproduce on my
machine here, neither on my autobuilder where the problem is reported
to occur.
I guess it is related to commit 05167a9ffa (package/make: add host
variant) which was applied on September 8, 23:36. Build seems to fail
only on hosts with make older than 4.0, so the host-make build is
triggered.
Yes, I figured that out after sending my summary. I reproduced the
issue on my build server, which has an old make installed system-wide,
and this issue seems to appear only when host-make is built prior to
boa. There's a mixup of make being used, with a new "make" used at the
top-level, passing options unknown to the old "make" used at the
lower-level.
Post by Baruch Siach
This failure is from before my patch bumping squid to 4.3 (commit
419c47a2135). But I believe we'll see the same failure with 4.3.
The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
only gcc 4.7 toolchain?
typedef double hbase_f(double);
class StatHist
{
...
hbase_f *val_in = nullptr; /* e.g., log() for log-based histogram */
hbase_f *val_out = nullptr; /* e.g., exp() for log based histogram */
}
For some reason this version of gcc considers val_in/val_out as
methods. But "fixing" the problem by changing the assignment to '= 0'
makes gcc segfault, not even ICE. So I think this is a compiler
bug. Should squid depend on gcc >= 4.8?
It would be nice to find an actual gcc bug report for this. I very much
prefer to document such issues using BR2_TOOLCHAIN_HAS_GCC_BUG_xyz
dependencies rather than semi-random gcc version dependencies.

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Peter Korsgaard
2018-10-11 09:48:22 UTC
Permalink
This post might be inappropriate. Click to display it.
Thomas Petazzoni
2018-10-11 14:12:31 UTC
Permalink
Hello,

+Romain Naour in Cc, since he added host-make to fix the glibc build.
Post by Peter Korsgaard
Post by Thomas Petazzoni
Yes, I figured that out after sending my summary. I reproduced the
issue on my build server, which has an old make installed system-wide,
and this issue seems to appear only when host-make is built prior to
boa. There's a mixup of make being used, with a new "make" used at the
top-level, passing options unknown to the old "make" used at the
lower-level.
Yeah, maybe, I didn't look closely, and I assumed the old version of
make is the one that didn't support the --jobserver-fds option.
Apparently, it's the opposite.
Post by Peter Korsgaard
usr/bin/make -j6 -C /home/peko/autobuild/instance-0/output/build/boa-0.94.14rc21/
make[1]: Entering directory `/home/peko/autobuild/instance-0/output/build/boa-0.94.14rc21'
(cd src && make -w --jobserver-fds=5,6 -j)
make: unrecognized option '--jobserver-fds=5,6'
So the issue is that we expand the path to make on the host in
package/Makefile.in:HOSTMAKE but then host-make installs make into the
path and build systems just calling make instead of looking at the MAKE
variable (which boa does because of its gnumake check) ends up with
host-make rather than the system one.
A quick fix would be to set BOA_MAKE to $(BR2_MAKE), but that is a bit
of a hack.
Perhaps we need to think about a more global solution. How do we want
to use host-make ? If it's compiled, should it be used to build all
packages ? Should it only be used for glibc ? In the latter case, how
do we "hide" it from all packages, and make it used only by glibc ?

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Peter Korsgaard
2018-10-11 15:25:38 UTC
Permalink
Hi,
Post by Thomas Petazzoni
Post by Peter Korsgaard
A quick fix would be to set BOA_MAKE to $(BR2_MAKE), but that is a bit
of a hack.
Perhaps we need to think about a more global solution. How do we want
to use host-make ? If it's compiled, should it be used to build all
packages ? Should it only be used for glibc ? In the latter case, how
do we "hide" it from all packages, and make it used only by glibc ?
Using it for everything is probably the simplest solution / most similar
to other tools.

If we only use it for glibc (for now), then we need to install it as
something else than 'make' (glibc-make? make-4?).
--
Bye, Peter Korsgaard
Thomas Petazzoni
2018-10-11 08:39:15 UTC
Permalink
Hello,
Post by Baruch Siach
The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
only gcc 4.7 toolchain?
typedef double hbase_f(double);
class StatHist
{
...
hbase_f *val_in = nullptr; /* e.g., log() for log-based histogram */
hbase_f *val_out = nullptr; /* e.g., exp() for log based histogram */
}
For some reason this version of gcc considers val_in/val_out as
methods.
They are function pointers, since hbase_f is a typedef of a function
that takes a double as argument and returns a double.

Indeed, the following minimal program:

typedef double hbase_f(double);

class StatHist
{
hbase_f *val_in = nullptr;
};

fails to build with gcc 4.7, but builds fine with a more recent gcc. It
would be good to find another gcc 4.7 toolchain to see if the same
problem occurs.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Peter Korsgaard
2018-10-11 10:42:43 UTC
Permalink
Hi,
Post by Baruch Siach
Post by Thomas Petazzoni
powerpc | squid-4.2 | NOK |
http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751
| ORPH
../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0' is allowed) before ';' token
../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0' is allowed) before ';' token
Not sure. Baruch, you recently bumped the squid package, could you have
a look ?
This failure is from before my patch bumping squid to 4.3 (commit
419c47a2135). But I believe we'll see the same failure with 4.3.
The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
only gcc 4.7 toolchain?
typedef double hbase_f(double);
Isn't there a * missing if this is a function pointer?

E.G.:

typedef double (*hbase_f)(double);

Unless this is something special in C++? Testing that on a 4.7.2
toolchain:

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)

g++ -std=c++11 -c t.cpp
t.cpp:5:27: error: invalid pure specifier (only ‘= 0’ is allowed) before ‘;’ token
g++ -std=c++11 -c t2.cpp
diff -u t.cpp t2.cpp
--- t.cpp 2018-10-11 12:35:32.122441311 +0200
+++ t2.cpp 2018-10-11 12:35:53.786261260 +0200
@@ -1,4 +1,4 @@
-typedef double hbase_f(double);
+typedef double (*hbase_f)(double);

class StatHist
--
Bye, Peter Korsgaard
Baruch Siach
2018-10-11 11:08:34 UTC
Permalink
Hi Peter,
Post by Peter Korsgaard
Post by Baruch Siach
Post by Thomas Petazzoni
powerpc | squid-4.2 | NOK |
http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751
| ORPH
../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0' is allowed) before ';' token
../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0' is allowed) before ';' token
Not sure. Baruch, you recently bumped the squid package, could you have
a look ?
This failure is from before my patch bumping squid to 4.3 (commit
419c47a2135). But I believe we'll see the same failure with 4.3.
The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
only gcc 4.7 toolchain?
typedef double hbase_f(double);
Isn't there a * missing if this is a function pointer?
typedef double (*hbase_f)(double);
Unless this is something special in C++? Testing that on a 4.7.2
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
g++ -std=c++11 -c t.cpp
t.cpp:5:27: error: invalid pure specifier (only ‘= 0’ is allowed) before ‘;’ token
g++ -std=c++11 -c t2.cpp
diff -u t.cpp t2.cpp
--- t.cpp 2018-10-11 12:35:32.122441311 +0200
+++ t2.cpp 2018-10-11 12:35:53.786261260 +0200
@@ -1,4 +1,4 @@
-typedef double hbase_f(double);
+typedef double (*hbase_f)(double);
Wouldn't that make the definition 'hbase_f *val_in' a pointer to
function pointer?

baruch


--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- ***@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Peter Korsgaard
2018-10-11 11:18:15 UTC
Permalink
Hi,
Post by Baruch Siach
Post by Peter Korsgaard
-typedef double hbase_f(double);
+typedef double (*hbase_f)(double);
Wouldn't that make the definition 'hbase_f *val_in' a pointer to
function pointer?
Not in C at least. The syntax is:

typedef <returntype> (*name)(<arguments>)

https://stackoverflow.com/questions/1591361/understanding-typedefs-for-function-pointers-in-c
--
Bye, Peter Korsgaard
Baruch Siach
2018-10-11 11:45:16 UTC
Permalink
Hi Peter,
Post by Peter Korsgaard
Post by Baruch Siach
Post by Peter Korsgaard
-typedef double hbase_f(double);
+typedef double (*hbase_f)(double);
Wouldn't that make the definition 'hbase_f *val_in' a pointer to
function pointer?
typedef <returntype> (*name)(<arguments>)
https://stackoverflow.com/questions/1591361/understanding-typedefs-for-function-pointers-in-c
Correct. But consider the SO example code:

typedef void (*SignalHandler)(int signum);

extern SignalHandler signal(int signum, SignalHandler handler);

The 'handler' parameter of the signal() function is a pointer to a
function. However the definition

SignalHandler *handler;

would create a pointer to a pointer. As I understand, this is not the
intention of the 'hbase_f *val_in' definition in the original code.

baruch

--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- ***@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Peter Korsgaard
2018-10-11 12:46:53 UTC
Permalink
Post by Baruch Siach
Hi Peter,
Post by Peter Korsgaard
Post by Baruch Siach
Post by Peter Korsgaard
-typedef double hbase_f(double);
+typedef double (*hbase_f)(double);
Wouldn't that make the definition 'hbase_f *val_in' a pointer to
function pointer?
typedef <returntype> (*name)(<arguments>)
https://stackoverflow.com/questions/1591361/understanding-typedefs-for-function-pointers-in-c
typedef void (*SignalHandler)(int signum);
extern SignalHandler signal(int signum, SignalHandler handler);
The 'handler' parameter of the signal() function is a pointer to a
function. However the definition
SignalHandler *handler;
would create a pointer to a pointer. As I understand, this is not the
intention of the 'hbase_f *val_in' definition in the original code.
Ehh, yes - But I was talking about the typedef line (as quoted
above). The * is needed for typedef but not for the val_in definition.
--
Bye, Peter Korsgaard
Giulio Benetti
2018-10-11 11:02:03 UTC
Permalink
Hello everybody,
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc | motion-release-4.1.1 | NOK | http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5 |
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:50: undefined reference to `drmGetVersion'
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:63: undefined reference to `drmFreeVersion'
Giulio, I believe you worked on this static linking problem between
ffmpeg and libdrm. What is the status of this ?
I still have to fix it and I'm currently illed(I think I need 1 week to
recover, I hope). Need also to ask something about solving it.
Going to do it on the e-mails regarding that patch.

Best regards
--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
Giulio Benetti
2018-10-20 15:22:58 UTC
Permalink
Hello,
Post by Giulio Benetti
Hello everybody,
Post by Thomas Petazzoni
Post by Thomas Petazzoni
powerpc | motion-release-4.1.1 | NOK | http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5 |
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:50: undefined reference to `drmGetVersion'
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:63: undefined reference to `drmFreeVersion'
Giulio, I believe you worked on this static linking problem between
ffmpeg and libdrm. What is the status of this ?
I've managed to fix it, I've submitted the patch:
https://patchwork.ozlabs.org/patch/985375/

Previous patch I've submitted was wrong, causing -ldrm to be linked both
in static and shared build, because of adding -ldrm to Libs: instead of
Libs.private in libavutil.pc.
But it's been upstreamed:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/c50dc77ac708e98d02da7c422a6b9cbf9f565aa5

After that I've tried to send a Revert:
https://patchwork.ffmpeg.org/patch/10696/
and re-submit this new patch:
https://patchwork.ffmpeg.org/patch/10697/
but they don't accept it:
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235283.html

I understand they only need a patch to improve the previous one, not the
entire patch I've submitted to Buildroot.

Anyway, is it correct I've submitted a unique patch(the first I've
listed) to Buildroot?

Otherwise I should submit 2 patches, the one already upstreamed:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/c50dc77ac708e98d02da7c422a6b9cbf9f565aa5
and the correction of it that I still have to send them.

Which is the better choice?
1 patch specific for Buildroot
or
2 patches, 1 already upstreamed and another to be upstreamed?

Sorry for my ignorance
Thanks in advance
Best Regards
--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
Thomas Petazzoni
2018-10-11 14:32:53 UTC
Permalink
Hello,
Post by Thomas Petazzoni
Seems like a musl/erlang issue. Johan, Frank, could you have a look ?
https://github.com/erlang/otp/pull/1981
I'll send a patch here next chance that I get.
Excellent, thanks!

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Giulio Benetti
2018-10-11 19:24:15 UTC
Permalink
Hello,

Il 10/10/2018 17:48, Thomas Petazzoni ha scritto:>> arm |
netsnmp-5.8 | NOK |
http://autobuild.buildroot.net/results/9f02e0f09ae2d2a66a8d33d73f1bdd45ea8b0f16
| ORPH
Post by Thomas Petazzoni
configure: error: The DTLS based transports require the libssl library from OpenSSL to be available and support DTLS
Bernd, you did the last version bump of netsnmp, could you have a look ?
I've submitted this patch for this:
https://patchwork.ozlabs.org/patch/970818/ that solves the build failure
above.

Bernd, please can you check it?
It works for me.
Is it formed ok that patch? (commit log, patches etc.)
I'm still waiting for 1 patch to be upstreamed.
--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
Loading...