Orangepi lite2 board has AP6356S WiFi/BT combo, but does
not have ethernet port. So it makes sense to enable wireless
networking by default:
- add broadcom wireless firmware package to image
- add basic wireless tools to image
- add rootfs overlay with proper NVRAM file for on-board AP6356S chip
- add mdev to image to enable module autoloading
- update readme.txt to test wifi
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add initial support for Orangepi Lite2 board with below features:
- U-Boot 2018.09
- Linux 4.19.0-rc8
- Default packages from buildroot
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add initial support for Orangepi One Plus board with below features:
- U-Boot 2018.09
- Linux 4.19.0-rc8
- Default packages from buildroot
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libpagekite is a C implementation of the backend of the PageKite relay
protocol. It allows external access to embedded devices without public
IP address.
There is a bundled version of libev but we prefer to use the global
libev library.
Although the configure script has a --without-openssl option, it
doesn't actually build without openssl.
Patch 0001-configure.ac-fix-handling-of-with.patch is needed because
we want to explicitly pass --with and --without options, even if they
are the default. The way the AC_ARG_WITH macros were used, --with and
--without both had the effect of enabling the option.
Patch 0002-configure.ac-use-AS_HELP_STRING-for-with-openssl.patch is
not needed for Buildroot, but it is part of the same upstream PR and
would generate a conflict for the next patch.
Patch 0003-configure.ac-use-pkg-config-for-openssl.patch is needed to
pass -lz (needed by openssl) in static compilation.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
[Thomas:
- As noticed by Romain Naour, fix the prompt of the package in the
Config.in
- Add entry to DEVELOPERS file
- Drop the dependency on BR2_bfin, since this architecture has been
dropped from Buildroot.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Added license hash, removed patches included in new version.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Removed upstream patches included in the new version.
Added upstream patch to fix build error.
Updated license hash after commit
http://w1.fi/cgit/hostap/commit/README?id=c2c6c01bb8b6fafc2074b46a53c4eab2c145ac6f
updated the copyright year.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
setup.py explicitly listed a maximum allowed version of python-requests,
causing runtime failures with the python-requests version we have:
Loaded image: docker-enp.bin.cloud.barco.com/eis/baseos-docker-snmp:0.1.0
Traceback (most recent call last):
File "/usr/bin/docker-compose", line 6, in <module>
from pkg_resources import load_entry_point
File "usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3123, in <module>
File "usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3107, in _call_aside
File "usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3136, in _initialize_master_working_set
File "usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 580, in _build_master
File "usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 593, in _build_from_requirements
File "usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 781, in resolve
pkg_resources.DistributionNotFound: The 'requests!=2.11.0,!=2.12.2,!=2.18.0,<2.19,>=2.6.1' distribution was not found and is required by docker-compose
FAIL
Upstream regularly updates setup.py as new python-requests releases are
made, but it is unknown why new python-requests releases (which are supposed
to be backwards compatible) should not be allowed right away.
Add a path submitted upstream to only disallow new major versions, similar
to how the other dependencies are handled.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
go 1.11.3 fixes the following security issues:
cmd/go: remote command execution during "go get -u"
The issue is CVE-2018-16873 and Go issue golang.org/issue/29230. See the Go issue for details.
Thanks to Etienne Stalmans from the Heroku platform security team for discovering and reporting this issue.
cmd/go: directory traversal in "go get" via curly braces in import paths
The issue is CVE-2018-16874 and Go issue golang.org/issue/29231. See the Go issue for details.
Thanks to ztz of Tencent Security Platform for discovering and reporting this issue.
crypto/x509: CPU denial of service in chain validation
The issue is CVE-2018-16875 and Go issue golang.org/issue/29233. See the Go issue for details.
Thanks to Netflix for discovering and reporting this issue.
go 1.11.4 fixes issues, including regressions introduced by 1.11.3:
1.11.4 includes fixes to cgo, the compiler, linker, runtime, documentation, go
command, and the net/http and go/types packages. It includes a fix to a bug
introduced in Go 1.11.3 that broke go get for import path patterns
containing "...".
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The 4.11.1 release brings a large number of fixes:
https://xenproject.org/downloads/xen-archives/xen-project-411-series/xen-4111.html
Including a number of security fixes:
XSA-268: Use of v2 grant tables may cause crash on ARM (CVE-2018-15469)
XSA-269: x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS
(CVE-2018-15468)
XSA-272: oxenstored does not apply quota-maxentity (CVE-2018-15470)
XSA-273: L1 Terminal Fault speculative side channel (CVE-2018-3620,
CVE-2018-3646)
XSA-275: insufficient TLB flushing / improper large page mappings with AMD
IOMMUs
XSA-276: resource accounting issues in x86 IOREQ server handling
XSA-277: x86: incorrect error handling for guest p2m page removals
XSA-278: x86: Nested VT-x usable even when disabled (CVE-2018-18883)
XSA-279: x86: DoS from attempting to use INVPCID with a non-canonical
addresses
XSA-280: Fix for XSA-240 conflicts with shadow paging
XSA-282: guest use of HLE constructs may lock up host
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As SHA256 is now default, removing weak MD5 option. C libraries now
all support the SHA methods.
glibc 2.7+
uclibc (bdd8362a88 package/uclibc: defconfig: enable sha-256...)
musl 1.1.14+
One issue this would prevent, is a host tool issue with a FIPS enabled
system where weak ciphers/methods are disabled. It seems the crypt(3)
call is impacted by /proc/sys/crypto/fips_enabled (per crypt(3) man
page). It results in mkpasswd returning "(EPERM) crypt failed."
Rather then create a Buildroot host dependency check, this patch
removes the potential corner case from being selected.
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch changes the default mkpasswd method to SHA256 from MD5.
The change both improves the quality of the hash used and prepares
for eventually removing MD5 as a option.
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch drops the comment about checking the C libraries version as
they now all support it by default
glibc 2.7+
uclibc (bdd8362a88 package/uclibc: defconfig: enable sha-256...)
musl 1.1.14+
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, U-Boot is failing to build, due to some issues
with the toolchain and the U-Boot port.
Fix it.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The build of host-libgtk3 calls $(HOST_DIR)/bin/pkgconf directly,
assuming that it will return correct results when building host
tools. It did work in practice without per-package directories, but is
not how pkg-config is used for host build in general: we recommend to
use $(HOST_DIR)/bin/pkg-config and we have in $(HOST_MAKE_ENV) a
number of environment variables that tell pkg-config to return results
relevant for host builds.
With per-package directories, calling $(HOST_DIR)/bin/pkgconf fails
badly, because it searches for .pc files in the per-package directory
of host-pkgconf itself, which obviously is empty.
So, we switch to using $(HOST_MAKE_ENV) $(PKG_CONFIG_HOST_BINARY),
which uses the regular pkg-config with the right environment
variables.
This allows the build of host-libgtk3 to find gdk-pixbuf-2.0 and
gio-2.0 built for the host, even in the context of
BR2_PER_PACKAGE_DIRECTORIES=y.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The mosquitto package provides both the MQTT client library and
a broker, and the latter may be not needed (when connecting to
a remote broker). It should be therefore possible to not install and
start it on the target
Also remove the dependency on BR2_TOOLCHAIN_HAS_SYNC_4, as it does not seem
to be needed. Verified with:
* br-m68k-68040-full.config [OK]
* br-sparc-uclibc.config [OK]
The original issue adding the dependency in commit 874d0784bb
(package/mosquito: needs sync_4) unfortunately refers to autobuilder results
that are no longer available.
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
[Peter: extend commit message, fix comment line, remove indentation in .mk]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump to 1.5.3, pkgconf prepends the sysroot to all absolute
paths found in the .pc file. This is correct when the paths refer to
something in STAGING_DIR (e.g. libdir, includedir), but not when it
refers to something used for the target.
vdr-plugin-vnsiserver uses the locdir variable from vdr.pc to decide
where to install things. Since DESTDIR is prepended to the install
destination, this will end up in the wrong location.
Until a better solution is found in pkgconf, pass the LOCDIR to use
explicitly instead of relying on vdr.pc.
Fixes:
- http://autobuild.buildroot.org/results/9be3719f7b2137a5f039f3c4209c3bc7edeae2b4
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since the bump to 1.5.3, pkgconf prepends the sysroot to all absolute
paths found in the .pc file. This is correct when the paths refer to
something in STAGING_DIR (e.g. libdir, includedir), but not when it
refers to something used for the target.
alsa-utils uses the systemdsystemunitdir variable from systemd.pc to
decide where to install things. Since DESTDIR is prepended to the
install destination, this will end up in the wrong location.
Until a better solution is found in pkgconf, pass the
systemdsystemunitdir to use explicitly instead of relying on systemd.pc.
Fixes:
- http://autobuild.buildroot.org/results/d8ad140ae52b4fe8e153de3835f3f17e92b58e53
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There are various versions shipped in linux-firmware. In the past we
decided that it was up to the developer to filter out the ones they want
for their specific kernel version, so install them all.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
luvi fails to run when it was build with CMake 3.12+:
```
[string "return require('init')(...)"]:1: module 'init' not found:
no field package.preload['init']
no file './init.lua'
no file '/usr/share/luajit-2.0.5/init.lua'
no file '/usr/local/share/lua/5.1/init.lua'
no file '/usr/local/share/lua/5.1/init/init.lua'
no file '/usr/share/lua/5.1/init.lua'
no file '/usr/share/lua/5.1/init/init.lua'
no file './init.so'
no file '/usr/local/lib/lua/5.1/init.so'
no file '/usr/lib/lua/5.1/init.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
```
Looking at link.txt for the luvi executable shows that `-rdynamic` is
not set anymore in CMake 3.12. This has the effect, that symbols are
missing in the `.dynsym` section in the binary.
The patch, sets `ENABLE_EXPORTS` to true in CMakeLists.txt to force setting
`-rdynamic` explicitly.
Upstream status: b8781653dcb8815a3019a77baf4f3b7f7a255ebe
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since the bump to 1.5.3, pkgconf prepends the sysroot to all absolute
paths found in the .pc file. This is correct when the paths refer to
something in STAGING_DIR (e.g. libdir, includedir), but not when it
refers to something used for the target.
kmod uses the completionsdir variable from bash-completions.pc to decide
where to install things. Since DESTDIR is prepended to the install
destination, this will end up in the wrong location.
Until a better solution is found in pkgconf, pass the appdefaultdir to
use explicitly instead of relying on bash-completions.pc.
Fixes:
- http://autobuild.buildroot.org/results/f8a1f956333062027294e766ff0ddab5c35d5887
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump to 1.5.3, pkgconf prepends the sysroot to all absolute
paths found in the .pc file. This is correct when the paths refer to
something in STAGING_DIR (e.g. libdir, includedir), but not when it
refers to something used for the target.
xapp_xdm uses the appdefaultdir variable from xt.pc to decide where to
install things. Since DESTDIR is prepended to the install destination,
this will end up in the wrong location.
Until a better solution is found in pkgconf, pass the appdefaultdir to
use explicitly instead of relying on xt.pc.
Fixes:
- http://autobuild.buildroot.org/results/08bcba7d7340f34dc66b5b2ab8fbcfbaee309e37
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump to 1.5.3, pkgconf prepends the sysroot to all absolute
paths found in the .pc file. This is correct when the paths refer to
something in STAGING_DIR (e.g. libdir, includedir), but not when it
refers to something used for the target.
xapp_xditview uses the appdefaultdir variable from xt.pc to decide where
to install things. Since DESTDIR is prepended to the install
destination, this will end up in the wrong location.
Until a better solution is found in pkgconf, pass the appdefaultdir to
use explicitly instead of relying on xt.pc.
Fixes:
- http://autobuild.buildroot.org/results/af70962c59ca3dd29d85207033125b2e7eda3e81
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump to 1.5.3, pkgconf prepends the sysroot to all absolute
paths found in the .pc file. This is correct when the paths refer to
something in STAGING_DIR (e.g. libdir, includedir), but not when it
refers to something used for the target.
xapp_xfd uses the appdefaultdir variable from xt.pc to decide where to
install things. Since DESTDIR is prepended to the install destination,
this will end up in the wrong location.
Until a better solution is found in pkgconf, pass the appdefaultdir to
use explicitly instead of relying on xt.pc.
Fixes:
- http://autobuild.buildroot.org/results/ea9884f4d676849d643d53275ebbc8668074a418
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump to 1.5.3, pkgconf prepends the sysroot to all absolute
paths found in the .pc file. This is correct when the paths refer to
something in STAGING_DIR (e.g. libdir, includedir), but not when it
refers to something used for the target.
xapp_xclock uses the appdefaultdir variable from xt.pc to decide where
to install things. Since DESTDIR is prepended to the install
destination, this will end up in the wrong location.
Until a better solution is found in pkgconf, pass the appdefaultdir to
use explicitly instead of relying on xt.pc.
Fixes:
- http://autobuild.buildroot.org/results/ea028467a981f419c395158c55aa9a6d16e3f2c1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump to 1.5.3, pkgconf prepends the sysroot to all absolute
paths found in the .pc file. This is correct when the paths refer to
something in STAGING_DIR (e.g. libdir, includedir), but not when it
refers to something used for the target.
xapp_xedit uses the appdefaultdir variable from xt.pc to decide where to
install things. Since DESTDIR is prepended to the install destination,
this will end up in the wrong location.
Until a better solution is found in pkgconf, pass the appdefaultdir to
use explicitly instead of relying on xt.pc.
Fixes:
- http://autobuild.buildroot.org/results/1b46f950fc0d957d04c0a60a24176d701ff16bd9
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump to 1.5.3, pkgconf prepends the sysroot to all absolute
paths found in the .pc file. This is correct when the paths refer to
something in STAGING_DIR (e.g. libdir, includedir), but not when it
refers to something used for the target.
xapp_xmap uses the appdefaultdir variable from xt.pc to decide where to
install things. Since DESTDIR is prepended to the install destination,
this will end up in the wrong location.
Until a better solution is found in pkgconf, pass the appdefaultdir to
use explicitly instead of relying on xt.pc.
Fixes:
- http://autobuild.buildroot.org/results/725c20ec9621a9c2d4b94784785bb481ff74f0e7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a maintenance release of the current stable WebKitGTK+ version,
which contains security fixes for CVE identifiers: CVE-2018-4437,
CVE-2018-4438, CVE-2018-4441, CVE-2018-4442, CVE-2018-4443, and
CVE-2018-4464. Additionally, it fixes a couple of build failures in
unusual build configurations.
Release notes can be found in the announcement:
https://webkitgtk.org/2018/12/13/webkitgtk2.22.5-released.html
More details on the issues covered by security fixes can be found
in the corresponding security advisory:
https://webkitgtk.org/security/WSA-2018-0009.html
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
