We currently call infra.smart_open() to open log files each time we
need to write to them.
Opening the file once in the constructor of Builder and Emulator and
writing to it whenever needed is simpler and slightly more efficient.
Remove smart_open and instead create a new open_log_file() function
which just opens the logfile. Also let it compute the filename, in
order to simplify even further the Builder and Emulator code.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is what the manpages usually do, and what Python does with the
automatically-added -h/--help parameter:
Before the change:
$ ./support/testing/run-tests
[...]
optional arguments:
-h, --help show this help message and exit
--list, -l list of available test cases
--all, -a execute all test cases
After the change:
$ ./support/testing/run-tests
[...]
optional arguments:
-h, --help show this help message and exit
-l, --list list of available test cases
-a, --all execute all test cases
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
has_broken_links makes it self-explanatory that this is a predicate
function, and that the return value tells whether there _are_ broken
links, not the opposite.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes#9871
gzip reads default command line options from the environment variable GZIP.
The fbgrab Makefile internally also uses a GZIP make variable to know what
command to use to compress the manpage. Unfortunaly make will export the
value of this make variable to the environment if GZIP is already present in
the enviroment, confusing gzip (as 'gzip' isn't a valid command line argument).
This can either be triggered by users having GZIP set in their environment
(E.G. for custom options), or by enabling BR2_REPRODUCIBLE, where we use
this feature to force the -n option (to not store name/timestamp) to gzip.
We don't really need to compress the manpage as it isn't installed anyway,
so work around the issue by only building the fbgrab application.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Previously was defined in qmi-util.h to fix musl
compatibility. It was missed that this is a shared
header which causes other dependent package builds
to fail, so the static definition was moved into the
implementation where it was used.
Upstream bug report has been updated and this resolves
the following autobuilder related failures.
http://autobuild.buildroot.net/results/fe9b6b1b1399a4e8aafc6a326c81ec97c2480025http://autobuild.buildroot.net/results/40eef797b4d8d53fc6e10f2048316d63549caf6d
test-pkg testing was performed against 10 random toolchains
++ Config snippet ++
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_MODEM_MANAGER_LIBQMI=y
BR2_PACKAGE_MODEM_MANAGER=y
BR2_PACKAGE_LIBQMI=y
++ Tested Toolchains ++ (Verified I hit all libc variants)
br-arm-cortex-a9-musl
br-arm-full-static
br-m68k-68040-full (uclibc)
br-mips32r6-el-hf-glibc
br-mips64-n64-full
br-mips64r6-el-hf-glibc
br-mipsel-o32-full
br-sparc64-glibc
linaro-arm
sourcery-arm
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
rabbitmq-c currently fails to build in a number of static linking
situations, due to two issues:
- CMake FindOpenSSL module is buggy. Even though it uses pkg-config,
it doesn't use the information returned by pkg-config, and
therefore doesn't know about second order libraries that need be
part of the link for static linking to succeed. Due to this, -lz is
not passed, and therefore rabbitmq-c fails when linking against
libssl/libcrypto. This issue has been reported to upstream CMake at
https://gitlab.kitware.com/cmake/cmake/issues/16885.
- popt might use libintl, but CMake doesn't know about that. For
autotools based packages, we typically work around this by passing
LIBS=, but CMake apparently has no equivalent to LIBS=.
To workaround this, we only use the OpenSSL and Popt optional
dependencies in dynamic linking situations.
Fixes:
http://autobuild.buildroot.net/results/798dbe5e5fd0463bb2066cb115656795144c327f/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes [1]:
main.cpp:(.text._ZN11QQmlPrivate10createIntoI6FbItemEEvPv[_ZN11QQmlPrivate10createIntoI6FbItemEEvPv]+0x18): undefined reference to `QQuickFramebufferObject::QQuickFramebufferObject(QQuickItem*)'
.obj/main.o: In function `QQmlPrivate::QQmlElement<FbItem>::~QQmlElement()':
main.cpp:(.text._ZN11QQmlPrivate11QQmlElementI6FbItemED2Ev[_ZN11QQmlPrivate11QQmlElementI6FbItemED5Ev]+0x5c): undefined reference to `vtable for QQuickFramebufferObject'
.obj/main.o: In function `QQmlPrivate::QQmlElement<FbItem>::~QQmlElement()':
main.cpp:(.text._ZN11QQmlPrivate11QQmlElementI6FbItemED0Ev[_ZN11QQmlPrivate11QQmlElementI6FbItemED0Ev]+0x64): undefined reference to `vtable for QQuickFramebufferObject'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0x48): undefined reference to `QQuickFramebufferObject::isTextureProvider() const'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0x4c): undefined reference to `QQuickFramebufferObject::textureProvider() const'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0xb4): undefined reference to `QQuickFramebufferObject::geometryChanged(QRectF const&, QRectF const&)'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0xb8): undefined reference to `QQuickFramebufferObject::updatePaintNode(QSGNode*, QQuickItem::UpdatePaintNodeData*)'
.obj/main.o:(.data.rel.ro._ZTVN11QQmlPrivate11QQmlElementI6FbItemEE[_ZTVN11QQmlPrivate11QQmlElementI6FbItemEE]+0xbc): undefined reference to `QQuickFramebufferObject::releaseResources()'
.obj/moc_fbitem.o: In function `FbItem::qt_metacast(char const*)':
moc_fbitem.cpp:(.text+0x70): undefined reference to `QQuickFramebufferObject::qt_metacast(char const*)'
.obj/moc_fbitem.o: In function `FbItem::qt_metacall(QMetaObject::Call, int, void**)':
moc_fbitem.cpp:(.text+0x80): undefined reference to `QQuickFramebufferObject::qt_metacall(QMetaObject::Call, int, void**)'
.obj/moc_fbitem.o: In function `FbItem::~FbItem()':
moc_fbitem.cpp:(.text._ZN6FbItemD2Ev[_ZN6FbItemD5Ev]+0x38): undefined reference to `vtable for QQuickFramebufferObject'
.obj/moc_fbitem.o: In function `FbItem::~FbItem()':
moc_fbitem.cpp:(.text._ZN6FbItemD0Ev[_ZN6FbItemD0Ev]+0x40): undefined reference to `vtable for QQuickFramebufferObject'
.obj/moc_fbitem.o:(.data.rel.ro+0x8): undefined reference to `typeinfo for QQuickFramebufferObject'
.obj/moc_fbitem.o:(.data.rel.ro+0x58): undefined reference to `QQuickFramebufferObject::isTextureProvider() const'
.obj/moc_fbitem.o:(.data.rel.ro+0x5c): undefined reference to `QQuickFramebufferObject::textureProvider() const'
.obj/moc_fbitem.o:(.data.rel.ro+0xc4): undefined reference to `QQuickFramebufferObject::geometryChanged(QRectF const&, QRectF const&)'
.obj/moc_fbitem.o:(.data.rel.ro+0xc8): undefined reference to `QQuickFramebufferObject::updatePaintNode(QSGNode*, QQuickItem::UpdatePaintNodeData*)'
.obj/moc_fbitem.o:(.data.rel.ro+0xcc): undefined reference to `QQuickFramebufferObject::releaseResources()'
.obj/moc_fbitem.o:(.data.rel.ro+0xf0): undefined reference to `QQuickFramebufferObject::staticMetaObject'
[1] http://autobuild.buildroot.net/results/64a/64a198397736db12b73c1f693dbe1c47d73b53da
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The protobuf library uses atomic intrinsics, so we need to link
against libatomic.
Fixes the build of protobuf on Sparc:
http://autobuild.buildroot.net/results/f3d76eaebd529a61bce849e355182c60f233ed06/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Boost fails to build with the following error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error: - <runtime-link>static <warnings>all
error: - <runtime-link>shared <warnings>on
when the following conditions are met:
- BR2_STATIC_LIBS=y
- BR2_PACKAGE_ICU=y
- BR2_PACKAGE_BOOST_LOCALE=y
- Another BR2_PACKAGE_BOOST_xyz option is enabled, which enables a
feature not provided just by header files, but that requires
building a library.
In such a situation, Boost absolutely wants to build the libboost
libraries as shared libraries. Not having boost-locale, or not having
icu is sufficient to avoid the issue.
So, as a simple work-around, we prevent from building boost-locale
when icu and static linking are used.
Fixes:
http://autobuild.buildroot.net/results/c8f7aa85f5791d8ae8cf4b9085788adc5152286f/
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas:
- only disable boost-locale when icu is enabled
- improve commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gcc on Microblaze is affected by PR63261, which causes a build failure
when optimization *and* debugging symbols are enabled. Since anyway
fxload is unlikely to be useful on Microblaze, let's disable this
package on this architecture.
Fixes:
http://autobuild.buildroot.net/results/24640a042d84f45339246c0a18e10905494b2199/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes:
- CVE-2015-8271: The AMF3CD_AddProp function in amf.c in RTMPDump 2.4 allows
remote RTMP Media servers to execute arbitrary code
https://www.talosintelligence.com/reports/TALOS-2016-0067/
- CVE-2015-8272: RTMPDump 2.4 allows remote attackers to trigger a denial of
service (NULL pointer dereference and process crash).
https://www.talosintelligence.com/reports/TALOS-2016-0068/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CVE-2017-8779: rpcbind through 0.2.4, LIBTIRPC through 1.0.1 and 1.0.2-rc
through 1.0.2-rc3, and NTIRPC through 1.4.3 do not consider the maximum RPC
data size during memory allocation for XDR strings, which allows remote
attackers to cause a denial of service (memory consumption with no
subsequent free) via a crafted UDP packet to port 111, aka rpcbomb.
For more details, see:
https://guidovranken.wordpress.com/2017/05/03/rpcbomb-remote-rpcbind-denial-of-service-patches/
Backport upstream fix to version 0.2.3 and unconditionally include syslog.h
to fix a build issue when RPCBIND_DEBUG is disabled (which it is in
Buildroot).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This fixes the following problem:
------------------------------------>8--------------------------------
arc-linux-gcc -c -Os -fPIC iso9660.i
iso9660.c: In function 'strip_trail':
iso9660.c:155:1: error: unrecognized supposed constant
}
^
(unspec:SI [
(symbol_ref:SI ("*.LANCHOR1") [flags 0x182])
] ARC_UNSPEC_GOTOFFPC)
iso9660.c:155:1: internal compiler error: in arc_legitimate_constant_p, at config/arc/arc.c:6028
------------------------------------>8--------------------------------
Found by Buildroot autobuilder [1].
The fix [2] is in arc-2017.03 development branch of ARC GCC and once it
becomes a part the next release of ARC tools this should be removed
from Buildroot.
[1] http://autobuild.buildroot.net/results/c90/c909e8c397ab972b6aa4d370572cad4fae284d00/build-end.log
[2] 139fed9d29
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The qv4l2 tool in libv4l uses clock_gettime(), so it should link
against librt to build properly with old versions of glibc. Therefore,
we add a patch to libv4l to fix this issue. Autoreconfiguring libv4l
is now necessary since the patch touches Makefile.am.
Fixes:
http://autobuild.buildroot.net/results/5dff0ec19205e02f6ee373d34cb79f39ac25b609/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit [1] added check package to bluez_utils dependencies without
selecting it at Kconfig level.
Fixes:
Makefile:535: *** check is in the dependency chain of bluez_utils that has added it to its _DEPENDENCIES variable without selecting it or depending on it from Config.in.
[1] 8554be9f82
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
lapack support is enabled by default but the opencv3.mk doesn't handle
this dependency yet.
Fixes:
http://autobuild.buildroot.net/results/c8a/c8a25af38c405594722b44aef34e5e4c549639db
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tests are enabled since this has been introduced [1], so keep
them for now.
bluez_utils needs check tool and check if it's available [2].
[1] 06c3e21596
[2] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/configure.ac?h=4.101#n51
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The commit bumping ARC tools to arc-2017.03-rc2 [1] forgot to
update the ARC tools version in binutils.mk
[1] 0437372820
Fixes:
http://autobuild.buildroot.net/results/f9c/f9c40610209fc22ac8c0db6bd57bd3b11bbe6d9c
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Makefile.sparc in the openblas source code passes -mcpu=v9, i.e it
assumes a SPARCv9 CPU. Therefore, this commit adjusts openblas
Config.in file so that SPARC is only used for BR2_sparc_v9.
Fixes:
http://autobuild.buildroot.net/results/805087e87b8bb7d11adb49d9eca3959a37aca3a2/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libcdio doesn't build on ARC, with the following compiler error:
iso9660.c:155:1: error: unrecognized supposed constant
[...]
iso9660.c:155:1: internal compiler error: in arc_legitimate_constant_p, at config/arc/arc.c:6028
Please submit a full bug report,
Since this has been happening for a while and is quite noisy in the
autobuilders results, we disable this package on ARC.
Fixes:
http://autobuild.buildroot.net/results/e837737abaea851bea428a35ea9d3395a6565c54/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since we do not have autocalculation anymore, the user must specify the
exact number of blocks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since the introduction of 4.11 kernel headers in Buildroot, radvd has
failed to build with all toolchains using this kernel header version.
The issue comes from the fact that radvd includes both <net/if_arp.h>
and <linux/if_arp.h> if they are available. Until 4.11,
<linux/if_arp.h> was in fact not included, because the
AC_CHECK_HEADERS() test concluded this header was unsuitable. This has
been fixed in the upstream kernel by commit
2618be7dccf8739b89e1906b64bd8d551af351e6 ("uapi: fix linux/if.h
userspace compilation errors"). So now, the radvd configure script
considers both <net/if_arp.h> and <linux/if_arp.h> as suitable
headers, and includes both of them, leading to the duplicate
definition of various types.
Since it's redundant to include both <net/if_arp.h> and
<linux/if_arp.h>, we simply force radvd to believe that
<linux/if_arp.h> is not available by passing the appropriate autoconf
cache variable. This gets us back to the previous situation, where
<linux/if_arp.h> was never used.
This has been tested with a uClibc toolchain using 4.11 kernel
headers, and verified to work on glibc and musl with older kernel
headers as well.
Fixes:
http://autobuild.buildroot.net/results/949a75d96299394e4ac957746fa23a4b52f31b43/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Running foo-source-check on packages retrieved from git fails.
This is because there is no associated stamp file, so we do not have a
rule-assignment that sets PKG for foo-source-check.
But it does not make sense to have a stamp file at all, because
source-check is not supposed to change anything: the status after is
exactly the same as before; nothing is downlaoded, so there is no
progress (whatsoever) to memorise.
Fix that by just defining PKG in the source-check rule definition.
Fixes#9796.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
odroid-scripts are just scripts, so they should also work on a armeb
board.
Besides, odroid-mali selects it, but it only depends on arm-eabihf,
which means armeb is not ruled out.
Fixes unmet dependencies (with BR2_armeb=y):
warning: (BR2_PACKAGE_ODROID_MALI) selects BR2_PACKAGE_ODROID_SCRIPTS
which has unmet direct dependencies(BR2_aarch64 || BR2_arm)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Dagg Stompler <daggs@gmx.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit bumps ARC toolchain to arc-2017.03-rc2
Please note that it is a release candidate and it might contain some
breakages, please don't use it for production builds.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When building on a systemd-based host for a systemd-based target, gpsd's
buildsystem will try to tell systemd to reload the its configuration and
recreate the entire dependency tree of services.
Of course, this can not work when run as a user:
>>> gpsd 3.16 Installing to target
==== AUTHENTICATING FOR org.freedesktop.systemd1.reload-daemon ===
Authentication is required to reload the systemd state.
Authenticating as: root
Password:
In fact, this does not even mean anything in cross-compilation.
Fortunately, upstream has already fixed their sin, so we backport it
(tweaked to apply onto 3.16).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This release contains "various security improvements in demuxers and
decoders".
Release notes: http://www.videolan.org/vlc/releases/2.2.5.html
Added all hashes provided by upstream.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Patch using renames are not properly handled by patch < 2.7, which
some users (including autobuilder instances) might be using. Such
renames are silently ignored by old patch versions, caused strange
build failures due to the missed renames.
This patch fixes this by regenerating the patch without renames.
Fixes:
http://autobuild.buildroot.net/results/347d8fd2e286b3e4e5e18743e64d862bdb66dbb9/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
kvm-unit-tests uses the following code on x86/x86-64:
static inline u64 scale_delta(u64 delta, u64 mul_frac)
{
u64 product, unused;
__asm__ (
"mul %3"
: "=d" (product), "=a" (unused) : "1" (delta), "rm" ((u64)mul_frac) );
return product;
}
The "mul" instruction does not have a suffix that indicates the width of
the data being multiplied. When the data is passed in a register, there
is no need to specify the width, but with some gcc versions, the data is
passed as a memory reference, and therefore the assembler does not know
the width of the data to be multiplied. It causes the following build
failure:
x86/hyperv_clock.c: Assembler messages:
x86/hyperv_clock.c:21: Error: no instruction mnemonic suffix given and no register operands; can't size instruction
Since the data being multiplied is 64 bit, we explicitly specify the
instruction as being "mulq".
Fixes:
http://autobuild.buildroot.net/results/a4a65d01f049db83a93de92660f228dd18532625/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
On master 86b4eeccc4, espeak can generate spurious 'unmet dependencies'
messages:
$ make KCONFIG_SEED=0x7A85DEE0 randconfig
warning: (BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_ALSA) selects
BR2_PACKAGE_PORTAUDIO_CXX which has unmet directdependencies
(BR2_PACKAGE_PORTAUDIO && BR2_INSTALL_LIBSTDCPP)
However, the dpendency chain *is* correct. There is something that
causes the kconfig parser to get really confused...
Add a comment statng the issue is spurious, so noone tries to fix it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnaud Aujon <arnaud@intelibre.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This adds '-static' to the link command when BR2_STATIC_LIBS=y, making the lua
binary really static.
Cc: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
