The weston runtime test uses the CRC of the framebuffer to detect that
"something" is being drawned on the framebuffer. This requires that the
sampling of the CRC happens does not happen too early after trigerring
an action, or the rendering may be not be finishe, either:
- weston may not have had time to initialise, or
- the test application may not have started rednering,
The sequence of rendering that has been observed yields this sequence of
CRCs (elided for brevity):
- boot:
- alternating between 0x4c4126bf and 0x5d2f9aa5: console cursor
blinking
- start weston:
- 0x4c4126bf: weston switches to a cleared vt, no blinking cursor
...
- 0xe54b7895: weston is starting
...
- 0xe54b7895: wayland socket appears!
...
- 0x6bf28bdf: weston is ready
...
- start weston-simple-egl:
- 0x6bf28bdf: application is starting
...
- 0xNNNNNNNN: random CRCs while the application renders
...
- stop weston-simple-egl:
- 0xNNNNNNNN: zero, one, or two random CRCs while the application
renders before it handles SIGTERM
- 0x6bf28bdf: application is stopped
...
- stop weston:
- 0x6bf28bdf: a few CRC identical to when weston was started, while
weston is processing SIGTERM
- oscillating between 0x4c4126bf and 0x5d2f9aa5: console cursor
blinking, back to initial vt, weston dead.
So, we need to wait "enough" after each action. Moreover, when the
wayland socket appears, weston may not have stabilised yet, so we also
need to wait after the socket appears.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Julien Olivain <ju.o@free.fr>
by using this standard extension `adoc`,
these files are rendered on gitlab & github
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When testing the virt machine with EDK2, the buildroot 6.1 kernel
will not boot as it has no base ACPI support. Whilst you can run
qemu with the -no-acpi option, it would help if basic ACPI support
was there as otherwise there is no output from the kernel post the
ACPI BIOS initialisation.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
pkg-config --variable=version luajit returns 2.1.1693350652 since bump of
luajit in commit c9dcd9e459, but the directory
is still host/share/luajit-2.1 - resulting in the following build failure:
luajitluajit:: unknown luaJIT command or jit.* modules not installedunknown luaJIT command or jit.* modules not installed
Fixes:
- http://autobuild.buildroot.org/results/d1cac93407122bb5a6e2c13f49b542e1db619fb5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With this version we can build with Linux 6.5.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Building go with cgo support needs to build some .c files to generate target
support code, and thus calls the cross C compiler, which is failing when the
toolchain is not built before host-go:
>>> host-go 1.21.1 Building
cd .../build/host-go-1.21.1/src && GO111MODULE=off GOCACHE=.../per-package/host-go/host/share/host-go-cache GOROOT_BOOTSTRAP=.../per-package/host-go/host/lib/go-1.19.11 GOROOT_FINAL=.../per-package/host-go/host/lib/go GOROOT=".../build/host-go-1.21.1" GOBIN=".../build/host-go-1.21.1/bin" GOOS=linux CC=/usr/bin/gcc CXX=/usr/bin/g++ CGO_ENABLED=1 CC_FOR_TARGET=".../per-package/host-go/host/bin/arm-linux-gcc" CXX_FOR_TARGET=".../per-package/host-go/host/bin/arm-linux-g++" GOOS="linux" GOARCH=arm GOARM=6 GO_ASSUME_CROSSCOMPILING=1 ./make.bash
Building Go cmd/dist using .../per-package/host-go/host/lib/go-1.19.11. (go1.19.11 linux/amd64)
go tool dist: cannot invoke C compiler [".../per-package/host-go/host/bin/arm-linux-gcc"]: fork/exec .../per-package/host-go/host/bin/arm-linux-gcc: no such file or directory
Go needs a system C compiler for use with cgo.
To set a C compiler, set CC=the-compiler.
To disable cgo, set CGO_ENABLED=0.
This happens systematically with PPD, and happens without PPD when
host-go is explicitly built (by running: "make host-go").
Since only CGO support needs to compile C files, only add the toolchain
dependency in that case.
When the target is not supported by go, then there is obviously no need
to depend on the toolchain (even if we unconditionally enable cgo
support in only-for-the-host host-go).
Signed-off-by: Christian Stewart <christian@aperture.us>
[yann.morin@orange.com:
- only add the toolchain dependency for target cgo
- reword commit log
]
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Anisse Astier <anisse@astier.eu>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 0c15169f5a (package/pppd: bump version to 2.5.0) forgot to drop
the check-package exclusion when it dropped the patches.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This is a simple test that builds and runs the futter-gallery application and
checks if the service is active.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: fix flake8 warnings]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Flutter Gallery is a resource to help developers evaluate and use Flutter.
It is a collection of Material Design & Cupertino widgets, behaviors, and
vignettes implemented with Flutter.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
flutter-pi is one of many flutter-embedders. However, flutter-pi is unique
because it doesn't require X or Wayland to run. So long as there is support for
KMS and DRI flutter-pi should run on any platform that flutter-engine supports.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: drop unused BR2_PACKAGE_FLUTTER_PI_TEST_PLUGIN]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
There are many issues with this package:
- The release tarballs from https://github.com/flutter/engine are in no state
to compile. They are only for the use of gclient to download a source
directory structure suitable to build the Flutter engine! If you download,
extract and attempt to run `./tools/gn --no-goma --no-prebuilt-dart-sdk`, you
receive the error message:
`No such file or directory: 'flutter/flutter/third_party/gn/gn.'
But wait! Wasn't the gn binary just called? No, that's a wrapper in the
Flutter source tree that formats arguments to call the real gn binary.
The real gn is not provided in the tarball but is downloaded via gclient
(among many other supporting repositories.)
Even worse, the flutter buildsystem depends on the .git dirs being present.
(https://github.com/meta-flutter/meta-flutter/issues/271) This dependency
means it is not possible to create a reproducible tarball from the downloaded
sources, which is why there is no .hash file provided.
I have asked the flutter project to release full tarballs suitable for
compiling here: https://github.com/flutter/flutter/issues/130734
- Flutter engine includes a patched copy of clang that must be used to compile.
Using a Buildroot-build clang results in linking warning and errors.
As such, we depend on LLVM_ARCH_SUPPORTS but use the included clang for
building. On the plus side, this saves time having to compile clang.
- flutter-engine relies on the "PUB_CACHE", that is provided by flutter-sdk,
so we need a build dependency, even if no tool from host-flutter-sdk-bin
is used to build flutter-engine
Tested with:
- Debian 11 and 12
- Ubuntu 18.04, 20.04, and 22.04
- Fedora 38
- Per-package directories
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr:
- search gclient.py from PATH
- indent shell script with 4 spaces
- reorganise schell script with prepare/cleanup
- tweak comment about weirdness of flutter buildsystem
- use suitable-extactor and TAR_OPTIONS
- use FLUTTER_SDK_BIN_PUB_CACHE
- add dependency to host-futter-sdk-bin (Adam)
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
flutter-sdk-bin is a collection of host tools and plugins used to compile
flutter applications.
- As this is a collection of pre-compiled tools, append -bin to the end of the
package name.
- We must set the HOME directory variable to the sdk directory or else the
flutter dart binaries place .dart, .dart-sdk, and .flutter in ~/.
- set --clear-features, --no-analytics and --disable-telemetry first to disable
google tracking as soon as possible.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr:
- set FLUTTER_SDK_BIN_PUB_CACHE for other packages to make use of it
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Chromium and Chromium OS use a package of scripts called
depot_tools to manage checkouts and code reviews. This package
also includes the gclient utility.
gclient is a Python script to manage a workspace of modular dependencies that
are each checked out independently from different subversion or git
repositories. Features include:
- Dependencies can be specified on a per-OS basis.
- Dependencies can be specified relative to their parent dependency.
- Variables can be used to abstract concepts.
- Hooks can be specified to be run after a checkout.
- .gclient and DEPS are Python scripts. You can hack in easily or add
additional configuration data.
.gclient file: It's the primary file. It is, in fact, a Python script. It
specifies the following variables:
- solutions: an array of dictionaries specifying the projects that will be
fetched.
- hooks: additional hooks to be run when this meta checkout is synced.
- target_os: an optional array of (target) operating systems to fetch
OS-specific dependencies for.
- cache_dir: Primarily for bots, multiple working sets use a single git
cache.
gclient is necessary for checking out the flutter-engine source code, as the
release tarballs provided on the flutter-engine github are in no state to
compile. Google expects the use of gclient to download a source directory
structure suitable to build the Flutter engine.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This is needed for the host-depot-tools package.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Removed all patches, they are now included in this release.
Added other patches fixing errors.
Removed option BR2_PACKAGE_PPPD_RADIUS, upstream build system, now auto-
conf-based, does not support disabling the radius plugin.
Removed BR2_PACKAGE_PPPD_OVERWRITE_RESOLV_CONF, upstream now defaults to
/etc, quoting README:
"Note that if you have built and installed previous versions of this
package and you want to continue having configuration and TDB files in
/etc/ppp, you will need to use the --sysconfdir option to ./configure."
Switched build system to autoconf, added optional systemd support.
Added configure option to enable multilink support which now defaults to
false but was enabled before:
https://github.com/ppp-project/ppp/blob/2.4.9/pppd/Makefile.linux#L57
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Patches (and so autoreconf) are not needed since bump to version 0.32.4
in commit f39ac8336e and
9924d4d315
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit updates monit to the latest 5.33.0 version which also
requires an additional patch to configure.ac as well as enabled ipv6
support.
Signed-off-by: Jens Maus <mail@jens-maus.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Remove no longer supported soup2 config option
We now build webkit with soup3 so we need to set wpe_api to 2.0 to
be compatible.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We can now significantly simplify the python-rtoml build using the
new setuptools-rust setup type introduced in the python package
infrastructure.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
We can now significantly simplify the python-orjson build using the
new maturin setup type introduced in the python package
infrastructure.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
We can now significantly simplify the python-cryptography build using
the new setuptools-rust setup type introduced in the python package
infrastructure.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The python-maturin build backend while itself is a pep517 backend
uses setuptools-rust for bootstrapping purposes.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Python has two build backends for packages that use Rust:
setuptools-rust and maturin. Both are provided by the pyo3 package
infrastructure (but that's not relevant for Buildroot).
The setuptools-rust build backend is a setuptools extension that is
capable of building python rust extensions.
The maturin build backend is a pep517 build extension that is itself
written in rust, it is itself bootstrapped using setuptools-rust but
is not itself a setuptools extension.
Both are from the pyo3 build infrastructure, so we add both of them in a
single patch. They also share a lot of the cargo-specific handling.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[Arnout: remove the _PYO3_ENV variables, the add little benefit]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
mali-driver now builds on Linux 6.5.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
While building host-localedef from glibc 2.38 sources, it uses the
features.h header from its sources that define _ISOC2X_SOURCE 1 as
soon as _GNU_SOURCE is defined.
_ISOC2X_SOURCE enable __GLIBC_USE_ISOC2X 1 that enable the header
redirection to use __isoc23_* functions introduced in glibc 2.38 [1].
If an older version is installed on the host, those functions
doesn't exist and break the build.
Add a local patch to keep _ISOC2X_SOURCE and __GLIBC_USE_ISOC2X
disabled.
Fixes:
host-localedef-2.38-13-g92201f16cbcfd9eafe314ef6654be2ea7ba25675/build/locale/ld-ctype.o: in function `ctype_read':
ld-ctype.c:(.text+0x6cef): undefined reference to `__isoc23_strtoul'
(glibc 2.31 installed on the host)
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=64924422a99690d147a166b4de3103f3bf3eaf6c
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Enable mathvec explicitly on aarch64(be) since it's now enabled by
default [1]. aarch64 mathvec requires at gcc-10 but Buildroot already
provide gcc-11 as minimum version.
Don't use --enable-fortify-source for now in order to keep original
behavior while doing the glibc version bump (and because some
architecture doesn't support well fortify-source, i.e Microblaze).
Postpone this change to a follow up commit.
Keep the "deprecated" libcrypt enabled just in case if some
application are not yet ready to use an alternative such as libxcrypt.
Security related changes:
CVE-2023-25139: When the printf family of functions is called with a
format specifier that uses an <apostrophe> (enable grouping) and a
minimum width specifier, the resulting output could be larger than
reasonably expected by a caller that computed a tight bound on the
buffer size. The resulting larger than expected output could result
in a buffer overflow in the printf family of functions.
See:
https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00010.html
Runtime tested with Qemu on Gitlab-ci:
https://gitlab.com/kubu93/buildroot/-/pipelines/998435203https://gitlab.com/buildroot.org/toolchains-builder/-/pipelines/998926028
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=cd94326a1326c4e3f1ee7a8d0a161cc0bdcaf07e
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Switch to cmake-package as autotools has been removed since version
9.0.0
- This bump will fix the following build failure with gcc 13 thanks to
b0b8937c56:
In file included from proj_json_streaming_writer.cpp:34:
proj_json_streaming_writer.hpp:42:14: error: 'int64_t' in namespace 'std' does not name a type
42 | typedef std::int64_t GIntBig;
| ^~~~~~~
https://github.com/OSGeo/PROJ/blob/9.3.0/NEWS
Fixes:
- http://autobuild.buildroot.org/results/68416dcbed1ece589a7438b085f57064fc20f87d
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
