There is a UID mistmatch and file permission problem. sudo-cwd.sh will
switch id every docker run command.
80e9c3454a was reverted due to
missing a toolchain.
Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
There is a UID mistmatch and file permission problem. sudo-cwd.sh will
switch id every docker run command.
This can be done like this,
./scripts/docker-run.sh ./scripts/sudo-cwd.sh CMD
But not to make build script, just include sudo-cwd.sh in docker-run.sh.
Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
Remove all support for Baytrail and Cherrytrail platforms, they
aren't supported on the "main" branch any more. To build SOF for them
use the "table-v2.2" branch.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Fixes commit d09844ab98 ("zephyr/docker-build.sh: match UID with
'adduser' instead of 'chgrp -R'")
Also clarify comment and add reference to new sudo-cwd.sh script.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Fixes commit d09844ab98 ("zephyr/docker-build.sh: match UID with
'adduser' instead of 'chgrp -R'")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This fixes SOF version.cmake which was just broken by a recent git
security update and started to fail like this:
```
-- SOF version.cmake starting at 2022-04-25T18:14:56Z UTC
-- /workdir/zephyr/.. is at git commit with parent(s):
fatal: unsafe repository ('/workdir' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /workdir
```
(example at https://github.com/thesofproject/sof/runs/6162885265)
chgrp -R was always an ugly hack because it was messing with
(persistent) file permissions on the host, outside the container. This
new adduser solution is unfortunately much more code but it does not
leak any side effect outside the container.
Do not fix scripts/docker-run.sh yet because there is still no UID
mismatch between Github Actions and the SOF container (they're both
1001) but add a warning + TODO.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Building in parallel is much faster but it makes logs unreadable and
build failures impossible to understand. This is especially true when
building with recent ALSA that produces of deprecation warnings, see
examples below. For test topologies the problem is even worse: its
XARGS parallel build provides no log at all.
To find what actually fails, it is required to fall back on a single
threaded and verbose build and this is achieved with the variables
USE_XARGS, NO_PROCESSORS and VERBOSE. Pass these through docker-run.sh
and CMake.
Examples from #5608https://github.com/thesofproject/sof/runs/5717553555?check_suite_focus=truehttps://sof-ci.01.org/sofpr/PR5608/build12556/build/tools.txt
ALSA pcm.c:1523:(parse_hw_config) deprecated fsync value 'codec_slave',...
ALSA pcm.c:1471:(parse_hw_config) deprecated bclk value 'codec_slave',...
ALSA pcm.c:1523:(parse_hw_config) deprecated fsync value 'codec_slave',...
ALSA pcm.c:1471:(parse_hw_config) deprecated bclk value 'codec_slave',...
ALSA pcm.c:1523:(parse_hw_config) deprecated fsync value 'codec_slave',...
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
It's super annoying and time-consuming to update the image and wonder
why the previous one is still used. Shortcuts are nice in interactive
use but pointless in scripts.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
There's frequent confusion between image ID and image digest: display
both.
Show both sof and thesofproject/sof.
Use set -x to display the full command that is run.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Pass PRIVATE_KEY_OPTION environment variable to docker to be able to
define external key for signing.
Suggested-by: Marc Herbert <marc.herbert@intel.com>
Signed-off-by: Jaska Uimonen <jaska.uimonen@intel.com>
... thanks to the docker --env option which is smart enough not to pass
anything when there is nothing to pass.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
t flag is used to allocate a pseudo-TTY, but in some cases pseudo-tty is
not support. Removed for more useage.
Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
Having a docker container that contains the cross compiler and host
dependencies eases setup and maintenance of local builds.
The container setup procedure is based of the wiki instruction. A few
more dependencies were added.
In addition to the ct-ng and xtensa-newlib steps, this container builds
top of tree alsa-lib and alsa-utils as distros seem to be slow to update
them with the needed topology features.
The docker-run.sh script is used to automatically bind mount local
soft.git and sof.git directories in to the container. This provides
build artifacts in the same place as a local "make" would.
Use it like the following:
./scripts/docker-run.sh make
./scripts/docker-run.sh ./scripts/xtensa-build-all.sh
etc...
The container only needs to be re-built when the toolchain or alsa
dependencies are modified.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Fred Oh