Fix the view of 'Image Recipes' under 'Configuration' to only show
image recipes that are not customised since custom images have their
own page.
[YOCTO #9111]
(Bitbake rev: 18a93b360301a5497d5c8ef74ab71f374f2ad210)
Signed-off-by: Dave Lerner <dave.lerner@windriver.com>
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The build dashboard doesn't show image and artifact files correctly,
as it shows the full filename for images and the filename plus
path relative to DEPLOY_DIR for artifacts.
Instead, show just the suffix for image files, and the basename
for artifact files.
(Bitbake rev: 8084dcdc283b4dc170f066c202f89d56ce1abbef)
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the 'New custom image' page, each image recipe name listed should
link to the corresponding image recipe details page, so that users can
look into what packages are installed by a certain image, and decide
based on that if they want to customise it or not.
This patch adds that missing link.
(Bitbake rev: a481af693bfef0171732c18c298e285986b82de3)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The search field at the top of our tables was using one of the Bootstrap
classes for text field sizing. Those classes are a bit rigid, resulting
in text fields too wide that made other table controls wrap.
Setting a maximum width to the search form using one of the span classes,
combined with a % width css declaration, make for text fields that
adapt a bit better to the horizontal space available in each table.
(Bitbake rev: 7833fab2e03f2d9a01ab9ad0a13c190382098b5e)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Our project pages have 4 tabs: builds, configuration, import layer and
new custom image. Even though we treat the 'configuration' as the
default tab, it comes second after the builds tab.
That's a bit strange: the default tab should be the first one listed.
This patch changes the tab order to put 'configuration' first.
(Bitbake rev: ccb90019489c2c324c2a5a60295e02280a2ec18f)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The existing breadcrumb does not always provide a link to the project
configuration page. When you are in the build history pages, you must go
back to the builds information first, and from there access the project
configuration. That feels very long.
Change the breadcrumb so that the project name item always provides a
link to the project configuration.
(Bitbake rev: 9910f3f292d35fc91215d550c5f123dcf18ab35d)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we use modal dialogs to display dependency information for
packages, we are hitting their maximum height relatively often. It is set
by default to 400px, which makes it a bit tight at a 1280x800 viewport
size.
Reduce the maximum height to 300px to make things a bit more
comfortable.
(Bitbake rev: e36001d61768979d66cba0f3d4f5a2aaf4af2cb7)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'add layer' button in the project configuration page remains enabled
after you add a layer. If you click it again, the same layer you just
added is added again.
This patch disables the 'add layer' button on click, to avoid this bit
of weirdness.
[YOCTO #8905]
(Bitbake rev: 63705f60035884a810fdd36e5a3fe10e411f23c7)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The form for naming new custom images shows you an error message when
the name already exists or you include an invalid character in it. But
when an error appears, the input field was missing the red highlight.
This patch applies the right class to the form controls whenever an
error message is shown.
(Bitbake rev: df342e7662179410467c47cd870180ea75f863d4)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The placeholder text in the form where you name your new custom images
didn't display fully. This patch fixes the styles so that the text shows
properly. It also changes the text itself to make it a bit shorter.
[YOCTO #9122]
(Bitbake rev: 9df802182b0b96295b148a1681c2265e72d8306b)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although the support for building more than one release and how we
handle the build directories is the subject of lively discussion, we all
seem to agree on removing the ability to change the release of a
project. The feature is currently not working but exposed to users,
which is not a happy state of affairs.
This patch comments out the controls that give access to the release
changing functionality to hide them from users, but does not touch
anything else. Once all moving pieces start to settle down, we can make
a final decision regarding this feature, and clean up the code
accordingly.
[YOCTO #8917]
(Bitbake rev: 3a8c6f7155517cd61a160595b81e7bed84ba4eaf)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
npm fetcher with support for shrinkwrap files and lockdown files to easily
download and install an npm package with strict dependency resolution.
The SRC_URI should be in the format of:
SRC_URI = "npm://registry.npmjs.org/;name=${PN};version=${PV}"
To add a shrinkwrap and lockdown file use:
NPM_SHRINKWRAP := "${THISDIR}/${PN}/npm-shrinkwrap.json"
NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"
(Bitbake rev: dec75bbc5d075acb322dad8b1c40d6bd518dc9fd)
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is useful as npm-lockdown uses sha1 because npm releases the sha1 of
packages and whilst this is undocumented it seems no other algorithm is
supported
(Bitbake rev: fd5d9011f6dd7029895b64d8a02d33185b9aa8ae)
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously the keys were put into the os-release package. The package
indexing code was also deploying the keys rather than only using the keys.
This change makes signing-keys.bb the only publisher of the keys and also
uses standard tasks that already have sstate.
(From OE-Core rev: 1e38068ac38dfd067655dfd41464e28439179306)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Forward port all existing patches and arrange them such such
uclibc-only and qemu-only patches appear first
Add new patches to fix build on uclibc ( 0019-0022 )
Convert the lnr sed operation into a static patch
Use PACKAGECONFIG setting to disable features for muls and uclibc
instead of modifying EXTRA_OECONF manually
Drop compat from PACKAGECONFIG, this options has been removed
from systemd
Tested/booted sato iamge on all qemus and qemux86-64 on uclibc
(From OE-Core rev: 50743301bd8c0c4817d039d08c9567d15243a74d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
v4.5-rc1 of the kernel splits the subcommand related files
from perf into a new library, this patch adds the modification
of the Makefile to preserve the --sysroot option as for
the other perf related Makefiles.
(From OE-Core rev: e46eae34ac71d28aa92feed369c2d92248ed3e19)
Signed-off-by: Martin Donnelly <martin.donnelly@ge.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When checking enabling buildhistory doesn't change anything but rootfs stamps,
just build core-image-minimal instead of -sato to reduce the time this test
takes.
(From OE-Core rev: e9b44579007cbaa24c6b39ff788be3a927797660)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's possible for findutils-native to get built. There's no point in this as
this is part of the expected host platform but this can introduce races or even
bugs (4.5.19 appears to have a leaking fd bug, resulting in asserts) so add it
to ASSUME_PROVIDED so it definitely won't get built.
(From OE-Core rev: b753dae334641480cb4a232ce240f9f56be5568f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Inherit upstream-version-is-even as minor-odd releases (such as 4.5.x) are
development snapshots.
Change the SRC_URI back to using GNU_MIRROR now we're not using a development
release but a stable tarball.
(From OE-Core rev: 0b3810bfb4c25d0a023045eab429c9401293375a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
:= causes none of _remove flags to work with uclibc
e.g. security flags where we remove ssp options for libcs
but it does not become effective for uclibc and hence
the build fails
(From OE-Core rev: 205b446f3fc4a9885179a66a8dab9d81bcc63dca)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RPM 5 cannot be built without beecrypt, therefore the EXTRA_OECONF
arguments to pass when the beecrypt PACKAGECONFIG is disabled should
enable the internal/bundled beecrypt.
[YOCTO #9150]
(From OE-Core rev: ed1c47e7c621491b892fb82bd18644dba42212b9)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes this build error with uclibc:
alsa-lib-1.1.0/src/topology/parser.c: In function 'snd_tplg_build_file':
alsa-lib-1.1.0/src/topology/parser.c:262:35: error: 'S_IRUSR' undeclared
(first use in this function)
open(outfile, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
(From OE-Core rev: 9ec2c6d4fd9c5c1f745f4d402922b73649ff6287)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Hash for libav LICENSE.md updated due to dropping libaacplus:
9ba54c1b82
(From OE-Core rev: 070253835c45c9eff7ad045d99277d13f9d03173)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
security flags add -pie -fpie to CFLAGS which is not
right options for compiling .so files, they are only
useful for compiling executables
(From OE-Core rev: 2735d096aef2d039d711c13c311bb6dba979f437)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop kconfig and options-group support
Forward port cross-localedef support
Assume ssp support in libc when building gcc-initial
(From OE-Core rev: 9c3d461c4d54d684b38ec4c038a1c3c2fb9923f0)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
waf.bbclass disables no-static-libs for all waf recipes, so we don't need to
have it explicitly disabled here now.
(From OE-Core rev: 6eb64cdd5296c42a46f3485bca403814eec55b2c)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
autotools.bbclass has enough variables now that we can use it instead of
hand-coding a do_configure.
(From OE-Core rev: c8bd926cfa2f74ca59c379072c40322605a76bd2)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The sdk_extraconf() method of setting the configuration was awkward
since you needed to set it in a class and then inherit that class since
function definitions aren't allowed in conf files. It seemed to me the
a neater way to do this was to read the extra lines from an additional
conf file sdk-extra.conf (which can be located in a conf/ directory
anywhere along BBPATH as with other configuration files).
(From OE-Core rev: b53edb86c65ad375df153017f245244ef97f3932)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Package names are actually case sensitive near as I can tell, so we
shouldn't be lowercasing them everywhere.
* Look for CMake packages in pkgdata and map those back to recipes,
so we aren't dependent on the hardcoded mappings (though those are
still preserved).
* Avoid duplicates in the unmapped package list
(From OE-Core rev: 2ddad52ccca07245eea43d9b844c6c7d4b667ca3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a means of extending the dependency extraction for autotools and
cmake.
Note: in order to have this work, you need to have an __init__.py in the
lib/recipetool directory within your layer along with the module
implementing the handlers, and the __init__.py needs to contain:
# Enable other layers to have modules in the same named directory
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
(From OE-Core rev: 915dea9f89cd737e5ba167c384e8d314c5c23c49)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I should have adjusted this in OE-Core commit
80a44e52609a89d9ffe816181ae193af491c06ac where the behaviour changed.
(From OE-Core rev: 13409a2b899bb74b8060c840b8c7ef8759d099cb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If files would be overwritten by the deployment, preserve them in a
separate location on the target so that they can be restored if you
later run devtool undeploy-target.
At the same time, also check for sufficient space before starting the
operation so that we avoid potentially failing part way through.
Fixes [YOCTO #8978].
(From OE-Core rev: a2da55712691bcf1066c53d813107d75213d6b10)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you want to put the target device back to exactly how it was before
devtool deploy-target started poking things into it, then it would make
things easier if you didn't have to figure out which recipes were
deployed. Now that we have the list stored on the target we can
determine this reliably, so add a -a/--all option to undeploy-target to
undeploy everything that has been deployed.
One of the side-effects of this is that the dry-run functionality for
undeploy-target had to be reimplemented to actually run the script on
the target, since we have no way of knowing what's been deployed from
the host side. We don't need to do the same for deploy-target though
since we know exactly which files will be deployed without referring to
the target.
(From OE-Core rev: 41fed83060f0041e14e455d1446397bda277d953)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When running devtool deploy-target, we save a list of deployed files,
and this list is used by devtool undeploy-target (or the next time
deploy-target is run if the list is present, in case any files have been
renamed or deleted since the first time). We were writing this file to
the host, but it makes more sense to write the list to the target
instead, so that if we for example swap in a different board, or switch
hosts, things will work as expected.
In order to do this properly we have to construct a shell script and
ship it over to the target so we can run it. The manifest is written out
to a hidden directory in the root (/.devtool).
Fixes [YOCTO #7908].
(From OE-Core rev: a16a0c9334b785e2df896266c8911a2c7a1806b8)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Get the default value for updateserver from the configuration file and
show it in the help; also only make the parameter optional if it's
specified. This means we can also drop the check in the function as
argparse will then ensure it's specified if there's no config setting.
(From OE-Core rev: 82497bde58fc8bdae8d8acfbf025a1a90b14cc3e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a long description used when running --help on the specific command.
(From OE-Core rev: eb7787d1652fd84a149fd394969f4f1099406051)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Naming these as "optional arguments" is perhaps slightly confusing since
some of the positional arguments might also be optional; in addition
it's rare (though possible) for options to be mandatory - up until
recently we had a recipetool option (-o) that was mandatory. It's not
perfect, but change it to "options" so it's at least a bit more
appropriate.
(From OE-Core rev: 55e675de6191bf7eccd26df29189f2a6faa40a20)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The listing of subcommands in the --help output for devtool was starting
to get difficult to follow, with commands appearing in no particular
order (due to some being in separate modules and the order of those
modules being parsed). Logically grouping the subcommands as well as
being able to exercise some control over the order of the subcommands
and groups would help, if we do so without losing the dynamic nature of
the list (i.e. that it comes from the plugins). Argparse provides no
built-in way to handle this and really, really makes it a pain to add,
but with some subclassing and hacking it's now possible, and can be
extended by any plugin as desired.
To put a subcommand into a group, all you need to do is specify a group=
parameter in the call to subparsers.add_parser(). you can also specify
an order= parameter to make the subcommand sort higher or lower in the
list (higher order numbers appear first, so use negative numbers to
force items to the end if that's what you want). To add a new group, use
subparsers.add_subparser_group(), supplying the name, description and
optionally an order number for the group itself (again, higher numbers
appear first).
(From OE-Core rev: e1b9d31e6ea3c254ecfe940fe795af44761e0e69)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we didn't make any changes to the file then there's no point warning
the user that we have done.
(From OE-Core rev: 391b9ba30d802ac420ddf382588e03e718861c01)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Dave Lerner
Elliot Smith
Belen Barros Pena
Richard Purdie
Brendan Le Foll
Randy Witt
Khem Raj
Maxin B. John
Martin Donnelly
Ross Burton
Andreas Müller
Joshua Lock
Andre McCurdy
Paul Eggleton