Ryan Coe [Thu, 13 Oct 2016 03:42:45 +0000 (20:42 -0700)]
libite: new package
Signed-off-by: Ryan Coe <bluemrp9@gmail.com>
[Thomas:
- rewrap Config.in help text
- improve license description] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Carlos Santos [Sun, 10 Jul 2016 01:16:09 +0000 (22:16 -0300)]
util-linux: allow disabling the basic set of tools
When even a single extra util-linux utility is enabled, the default
build and install will install many more programs, including many that
overlap with those offered by busybox.
Fix by reworking the install-utilies menu to take advantage of the new
--disable-all-programs config option. This option make it possible to
disable the basic set of apps, and then enable only the desired apps.
Original patch by Danomi Manchego, visible at
http://patchwork.ozlabs.org/patch/494866/
Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
[Thomas/Arnout: remove the choice between all/custom/no, and simply have
a list of options with the basic set of tools, and then one option for
each tool. This gives the same flexibility, but avoids the choice, which
is never nice to have.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Carlos Santos [Sun, 10 Jul 2016 01:16:08 +0000 (22:16 -0300)]
util-linux: expand selection of libraries and utilities
- Add option to control installation of libfdisk
- Add libfdisk license to the comment in util-linux.mk
- List all utilities provided by the basic set and document that
linux32, linux64, uname26, i386 and x86_64 are symlinks to setarch
- Add options to install cal, ipcrm, ipcs, logger, lslogin and pg
Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
[Thomas: add missing dependency of the new lslogins option on
libsmartcols, and therefore !MMU.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Carlos Santos [Sun, 10 Jul 2016 01:16:06 +0000 (22:16 -0300)]
util-linux: clean up libraries and tools selections
Fix several problems in the package recipe:
- Make 'bool "lib<foo>"' the first item in each block
- Move the depends before the selects
- Add missing dependencies on BR2_USE_MMU, for fork()
- Improve help for cramfs utilities and login utilities
Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
[Thomas:
- remove capitalization of prompts, for consistency
- add missing dependencies on libsmartcols, and therefore !MMU] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gzip's configure uses $SHELL to find a POSIX-compliant shell to put in
the shebang of its shell scripts (zcat, gzexe, ...). However, we set
$SHELL to /bin/bash in the Makefile, which may not be present on the
target. We do make sure that /bin/sh always points to a valid shell on
the target so we can use that.
The configure discovery is completely broken for cross-compilation. The
same $SHELL is used during the build (it is used by make to run the
commands in rules) and on the target. Also, the checks for a valid
shell use the host shell, not the target shell.
We could try to patch gzip to fix that, but the checks can anyway not
be run for the target shell, so we'll have to override it with a cache
value anyway. So we can just as well do exactly that, without patching.
- Switch to GitHub.
- Remove LD=CC logic in libscsi.mk. This is now handled by the configure
script.
- Add patch to fix unsafe include paths issues. This patch has been sent
upstream as a pull request.
- Use a hook to create the m4 directory so autoreconf doesn't fail.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann E. MORIN [Fri, 14 Oct 2016 14:39:22 +0000 (16:39 +0200)]
core: allow a br2-external tree to override a defconfig
Currently, it is not possible for a br2-external tree to override a
defconfig bundled in Buildroot, nor is it possible to override one from
a previous br2-external tree in the stack.
However, it is interesting that a latter br2-external tree be able to
override a defconfig:
- the ones bundled in Buildroot are minimalist, and almost always
build a toolchain, so a br2-external tree may want to provide a
"better" defconfig (better, in the sense "suited for the project");
- similarly for a defconfig from a previous br2-external tree.
But we can't do that, as the rules for the defconfigs are generated in
the order the br2-external trees are specified, all after the bundled
defconfigs. Those rule are patten-matching rules, which means that the
first one to match is used, and the following ones are ignored.
Add a new utility macro, 'reverse', inspired from GMSL, that does what
it says: reverse a list of words.
Use that macro to reverse the list of br2-external trees, so that the
latters win over the formers, and even over bundled ones.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Julien CORJON <corjon.j@ecagroup.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Fri, 14 Oct 2016 14:39:20 +0000 (16:39 +0200)]
core: add support for multiple br2-external trees
Currently, we only support at most one br2-external tree. Being able
to use more than one br2-external tree can be very useful.
A use-case would be for having a br2-external to contain the basic
packages, basic board defconfigs and board files, provided by one team
responsible for the "board-bringup", while other teams consume that
br2-external as a base, and complements it each with their own set of
packages, defconfigs and extra board files.
Another use-case would be for third-parties to provide their own
Buildroot packaging in a br2-external tree, along-side the archives for
their stuff.
Finally, another use-case is to be able to add FLOSS packages in a
br2-external tree, and proprietary packages in another. This allows
to not touch the Buildroot tree at all, and still be able to get in
compliance by providing only that br2-external tree(s) that contains
FLOSS packages, leaving aside the br2-external tree(s) with the
proprietary bits.
What we do is to treat BR2_EXTERNAL as a colon-separated (space-
separated also work, and we use that internally) list of paths, on which
we iterate to construct:
- the list of all br2-external names, BR2_EXTERNAL_NAMES,
- the per-br2-external tree BR2_EXTERNAL_$(NAME) variables, which
point each to the actual location of the corresponding tree,
- the list of paths to all the external.mk files, BR2_EXTERNAL_MKS,
- the space-separated list of absolute paths to the external trees,
BR2_EXTERNAL_DIRS.
Once we have all those variables, we replace references to BR2_EXTERNAL
with either one of those.
This cascades into how we display the list of defconfigs, so that it is
easy to see what br2-external tree provides what defconfigs. As
suggested by Arnout, tweak the comment from "User-provided configs" to
"External configs", on the assumption that some br2-external trees could
be provided by vendors, so not necessarily user-provided. Ditto the menu
in Kconfig, changed from "User-provided options" to "External options".
Now, when more than one br2-external tree is used, each gets its own
sub-menu in the "User-provided options" menu. The sub-menu is labelled
with that br2-external tree's name and the sub-menu's first item is a
comment with the path to that br2-external tree.
If there's only one br2-external tree, then there is no sub-menu; there
is a single comment that contains the name and path to the br2-external
tree.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Julien CORJON <corjon.j@ecagroup.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Fri, 14 Oct 2016 14:39:18 +0000 (16:39 +0200)]
docs/manual: document the br2-external NAME
Update the manual with the new external.desc mandatory file.
Take the opportunity to add a section listing all mandatory files,
Config.in, external.mk and the new external.desc, instead of just
hinting about them in the external package recipes section.
Change the examples to use the NAME-suffixed variable instead of the
raw BR2_EXTERNAL variable.
Change all references to BR2_EXTERNAL elsewhere in the manual to now
use the 'br2-external tree' terminology.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Julien CORJON <corjon.j@ecagroup.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Fri, 14 Oct 2016 14:39:17 +0000 (16:39 +0200)]
core: introduce per br2-external NAME
This unique NAME is used to construct a per br2-external tree variable,
BR2_EXTERNAL_$(NAME)_PATH, which contains the path to the br2-external
tree.
This variable is available both from Kconfig (set in the Kconfig
snippet) and from the .mk files.
Also, display the NAME and its path as a comment in the menuconfig.
This will ultimately allow us to support multiple br2-external trees at
once, with that NAME (and thus BR2_EXTERNAL_$(NAME)) uniquely defining
which br2-external tree is being used.
The obvious outcome is that BR2_EXTERNAL should now no longer be used to
refer to the files in the br2-external tree; that location is now known
from the BR2_EXTERNAL_$(NAME)_PATH variable instead. This means we no
longer need to expose, and must stop from from exposing BR2_EXTERNAL as
a Kconfig variable.
Finally, this also fixes a latent bug in the pkg-generic infra, where we
would so far always refer to BR2_EXTERNAL (even if not set) to filter
the names of packages (to decide whether they are a bootloader, a
toolchain or a simple package).
Note: since the variables in the Makefile and in Kconfig are named the
same, the one we computed early on in the Makefile will be overridden by
the one in .config when we have it. Thus, even though they are set to
the same raw value, the one from .config is quoted and, being included
later in the Makefile, will take precedence, so we just re-include the
generated Makefile fragment a third time before includeing the
br2-external's Makefiles. That's unfortunate, but there is no easy way
around that as we do want the two variables to be named the same in
Makefile and Kconfig (and we can't ask the user to un-quote that variable
himself either), hence this little dirty triple-inclusion trick.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Fri, 14 Oct 2016 14:39:15 +0000 (16:39 +0200)]
core: offload handling of BR2_EXTERNAL into the script
Currently, we treat the case where we have no br2-external tree
(BR2_EXTERNAL is empty) differently from the case where we do have one
(BR2_EXTERNAL is not empty).
There is now no reason to treat those two cases differently:
- the kconfig snippet is always generated appropriately (i.e. it would
include the br2-external tree if set, or include nothing otherwise);
- we no longer have a dummy br-external tree either.
Also, the Makefile code to handle BR2_EXTERNAL is currently quite
readable if at least a little bit tricky.
However, when we're going to add support for using multiple br2-external
trees simultaneously, this code would need to get much, much more complex.
To keep the Makefile (rather) simple, offload all of the handling of
BR2_EXTERNAL to the recently added br2-external helper script.
However, because of Makefiles idiosyncracies, we can't use a rule to
generate that Makefile fragment.
Instead, we use $(shell ...) to call the helper script, and include the
fragment twice: once before the $(shell ...) so we can grab a previously
defined BR2_EXTERNAL value, a second time to use the one passed on the
command line, if any.
Furthermore, we can't error out (e.g. on non-existent br2-external tree)
directly from the fragment or we'd get that error on subsequent calls,
with no chance to override it even from command line.
Instead, we use a variable in which we store the error, set it to empty
before the second inclusion, so that only the one newly generated, if
any, is taken into account.
Since we know the script will always be called from Makefile context
first, we know validation will occur in Makefile context first. So we
can assume that, if there is an error, it will be detected in Makefile
context. Consequently, if the script is called to generate the kconfig
fragment, validation has already occured, and there should be no error.
So we change the error function to generate Makefile code, so that
errors are caught as explained above.
Lastly, when the value of BR2_EXTERNAL changes, we want to 'forget'
about the previous value of the BR2_EXTERNAL_MK variable, especially in
the case where BR2_EXTERNAL is now set to empty, so that we do not try
to include it later. That's why we first generate empty version of
BR2_EXTERNAL_MK, and then assign it the new value, if any.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Fri, 14 Oct 2016 14:39:14 +0000 (16:39 +0200)]
core: get rid of our dummy br2-external tree
Now that we generate a kconfig snippet, we can conditionally include the
BR2_EXTERNAL's Config.in only when BR2_EXTERNAL is supplied by the user,
which means our empty/dummy Config.in is no needed.
As for external.mk, we can also include it only when BR2_EXTERNAL is
supplied by the user, which means our empty/dummy external.mk is no
longer needed.
Ditch both of those files, and:
- only generate actual content in the Kconfig snippet when we actually
do have a BR2_EXTERNAL provided by the user (i.e. BR2_EXTERNAL is not
empty);
- add a variable that contains the path to the external.mk provided by
the user, or empty if none, and include the path set in that variable
(make can 'include' nothing without any problem! ;-) )
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Julien CORJON <corjon.j@ecagroup.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Fri, 14 Oct 2016 14:39:13 +0000 (16:39 +0200)]
core: do not hard-code inclusion of br2-external in Kconfig
Move the inclusion of br2-external's Config.in to the generated kconfig
snippet.
This will ultimately allow us to use more than one br2-external tree.
Offload the "User-provided options" menu to the generated Kconfig
snippet. We can also move the definition of the Kconfig-version of
BR2_EXTERNAL into this snippet.
We introduce an extra check that was not present in the previous code,
to check that we do have permission on that directory. Prevciously, it
was handled as a side effect of not being able to cd into there, but it
is cleaner to check it expressly.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmd/6c
/home/buildroot/br2/output/build/host-go-bootstrap-1.4.2/src/cmd/6c/txt.c: In function 'gmove':
/home/buildroot/br2/output/build/host-go-bootstrap-1.4.2/src/cmd/6c/txt.c:995:28: error: left shift of negative value [-Werror=shift-negative-value]
f->vconst |= (vlong)~0 << 32;
^~
/home/buildroot/br2/output/build/host-go-bootstrap-1.4.2/src/cmd/6c/txt.c:1045:28: error: left shift of negative value [-Werror=shift-negative-value]
f->vconst |= (vlong)~0 << 32;
^~
cc1: all warnings being treated as errors
not yet caught by autobuilders using this defconfig:
The blind option BR2_GCC_SUPPORTS_GRAPHITE was used to distinguish gcc
versions that support the graphite loop optimizer. But since a while
already, all the versions we support do support graphite. So this symbol
isn't needed anymore.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The blind option BR2_GCC_NEEDS_MPC was used to distinguish gcc versions
that rely on the mpc library and the ones that don't. But since a while
already, all the versions we support do need the mpc library. So this
symbol isn't needed anymore.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: François Perrad <francois.perrad@gadz.org>
[Thomas et al.: make those perl modules only required when mpv is enabled.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ExtUtils::MakeMaker is one of the Perl Core modules usually packaged in
Perl package for a Debian/Ubuntu based system.
For a Fedora based system, each Perl Core modules have their own RPM
package. So install only Perl package is not enough.
Fixes:
>>> host-libxml-parser-perl 2.41 Configuring
[...]
perl `which perl` Makefile.PL
Can't locate ExtUtils/MakeMaker.pm in @INC (you may need to install the ExtUtils::MakeMaker module)
Bernd Kuhls [Sat, 11 Jun 2016 16:30:19 +0000 (18:30 +0200)]
package/qt: Avoid X11 header collision with OpenGL/EGL
Including X11 headers via EGL/egl.h leads to a collision of defines
between Qt and X11. To fix this qt5 added
DEFINES += MESA_EGL_NO_X11_HEADERS
in various files:
The BR2_DEPRECATED logic is a lot less useful than the legacy handling,
because the symbols just disappears without warning to the user. For
example, we had a few defconfigs that were using deprecated symbols
(which were not actually used because BR2_DEPRECATED wasn't set) so
these didn't build the expected code anymore.
Also, the idea behind BR2_DEPRECATED is that you can easily revive it
again if there is interest. However, it is relatively easy to revert
the removal of a package as well.
The deprecation is also more effort because it has to be removed twice:
once when deprecating, and once when really removing.
It doesn't make sense to add a legacy entry for BR2_DEPRECATED. Users
who actually used it will get legacy warnings instead.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Binutils was locked down to 2.24 because U-Boot 2014.01 didn't build
with more recent binutils. However, this doesn't work anymore because
binutils 2.24 is deprecated.
Current U-Boot 2016.09.01 doesn't work out of the box because the
u-boot-nand.img support has been removed.
Since updating U-Boot is generally not needed anyway, we just remove
the U-Boot support.
Binutils was locked down to 2.24 because U-Boot 2014.01 didn't build
with more recent binutils. However, this doesn't work anymore because
binutils 2.24 is deprecated.
Current U-Boot 2016.09.01 does build successfully, but we don't have a
board anymore to test it.
Since updating U-Boot is generally not needed anyway, we just remove
the U-Boot support.
James Knight [Thu, 29 Sep 2016 21:26:29 +0000 (17:26 -0400)]
rapidxml: add patch to fix usage with gcc 4.7+
The official `rapidxml` package release only supports up to GCC 4.6.x
for all capabilities. Implementers attempting to include the file
"rapidxml_print.hpp" will all result in a compilation failure when using
a currently supported Buildroot GCC version (all 4.7+ at this time).
With the provided patch, dependent packages will be able to use all of
rapidxml's capabilities using a generated toolchain from Buildroot (let
alone external toolchains).
Signed-off-by: James Knight <james.knight@rockwellcollins.com>
[Thomas: rework patch so that it contains the proper line endings, and
applies properly without a pre-patch hook to convert the line endings
beforehand.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bump kernel revision used by lego_ev3_defconfig to the latest tag from
ev3dev, as suggested by Peter. This is a 4.4 series kernel, which has the
added benefit of not necessitating a specific gcc to boot.
We need a patch to create an empty drivers/lego/Kconfig file for the build
to succeed though, as the ev3dev kernel normally expects a drivers tree to
be checked out there.
Thomas Petazzoni [Sat, 15 Oct 2016 20:15:13 +0000 (22:15 +0200)]
configs/arm_juno: use official kernel tarball
Since commit 0924208839336f1a1bb29eb1a627005ba6b9065d ("configs/arm_juno: use 4.6
mainline kernel"), we're using a mainline kernel for the ARM Juno
board. But we're still fetching it from a Git repository, which is not
really efficient, so let's switch to use a tarball instead.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann E. MORIN [Sat, 15 Oct 2016 16:10:51 +0000 (18:10 +0200)]
package/kodi: needs .py modules
Kodi segfaults as soon as it tries to load a python module:
Could not find platform independent libraries <prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
ImportError: No module named site
Segmentation fault
Turns out that keeping .py modules (with or without .pyc) fixes the
issue.
Currently, Kodi selects python, but since the format of modules is a
choice, we can not select it.
Fix that by inverting the dependency on python from Kodi:
- turn it into a depends rather than a select,
- add the dependency to ! pyc-only
- update the comment accordingly.
In addition, the !MMU and !static dependencies are updated since they
are no longer needed for Python (we now depend on it rather than
selecting it), but for other packages. The !MMU dependency is moved to
the _ARCH_SUPPORTS symbol as well.
Also, we can no longer "select BR2_PACKAGE_SAMBA4", because samba4
selects python, and we can no longer select python. Therefore, we switch
to a "depends on" dependency for samba4, which is fine as a user willing
to use Kodi with Samba will certainly realize that Samba should be
enabled.
Fixes bug #9221.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas:
- update on latest master
- take care of the !MMU/!static dependencies.
- take care of the samba4 problem.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This configuration allows out-of-the box Digilent Zybo
support. It uses mainline U-boot and Linux kernel.
This configuration generates a SD card image named sdcard.img.
[Peter: rename genimage.cfg, cleanup post-image script, enable VFP support,
use 4.6 kernel headers and add tools needed by genimage] Signed-off-by: Sebastien Van Cauwenberghe <svancau@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add a target configuration for the beaglebone that supports the SGX530
graphics acceleration and builds the qt5 demos with the eglfs backend.
The imagination technologies demos and fbv are also included. The Linux
kernel is based on the omap2plus defconfig, a config fragment adds the
required settings for SGX accelerator support.
Signed-off-by: Lothar Felten <lothar.felten@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
configs/beaglebone: update kernel/uboot, add AM335x EVM support
This patch updates the target config for the beaglebone based on the
AM335x CPU. It also supports the beagleboneblack, the TI evm and evmsk.
Device tree blobs for am335x-evm, am335x-evmsk, am335x-bone,
am335x-boneblack will be built and a sd card image is created with a
post-image script. The kernel and driver versions match the
ti-processor-sdk 02.00.00.00. Patches allow the use of old AM335x evm
revisions (1 bit sd card) and JTAG debugging.
Kernel JTAG patch: By default the kernel will disable the JTAG clock,
access via the JTAG port will not work after the kernel booted. The
AM335x-evm has a JTAG header fitted, this patch keeps the JTAG clock
alive.
Signed-off-by: Lothar Felten <lothar.felten@gmail.com>
[Thomas: remove 1-bit MMC patch, it's causing a significant performance
regression for users of BeagleBone, which are 99.99% of the users of
this defconfig.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas Petazzoni [Sat, 15 Oct 2016 13:53:18 +0000 (15:53 +0200)]
gcc: add patches to fix PR70473
gcc 5.x introduced a regression in the ARM build, which causes the
s-automata program to consume a very significant amount of RAM during
the gcc build. This causes numerous failures with our Travis-CI based
testing of defconfigs.
In order to address this, this commit backports a commit from the gcc
master branch, to both our gcc 5.x and gcc 6.x support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sat, 15 Oct 2016 13:54:45 +0000 (15:54 +0200)]
DEVELOPERS: change developer for wpa_supplicant
The wpa_supplicant was in fact no introduced by Peter, but by Gustavo,
and Gustavo is much more active in maintaining this package, so let's
mention Gustavo as the developer for this package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas Petazzoni [Sat, 15 Oct 2016 13:53:36 +0000 (15:53 +0200)]
DEVELOPERS: update entry for gcc
Refering to package/gcc/gcc-initial and package/gcc/gcc-final was not a
good idea, as it doesn't notify when gcc patches are
added/removed/modified, so change this to package/gcc so that it catches
all changes.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Matt Kraai [Tue, 11 Oct 2016 02:46:00 +0000 (19:46 -0700)]
qt53d, qt5serialbus: move to technology preview section
As explained in
https://wiki.qt.io/New_Features_in_Qt_5.6#Technology_Preview_Modules,
not only qt5quickcontrols2 is a technology preview component in Qt 5.6,
but also qt53d, qt5serialbus.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
[Thomas: improve commit log with a reference.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
projects / coffee / buildroot.git / log