There is a bug in bash where BASH_COMMAND is not correct when an error
is hit in a subshell (it retains the command run *before* the subshell).
Since this has confused a few people using image_to_vm.sh so far, drop
the use of subshells in this file. They weren't necessary in the first
place so it isn't like we're losing anything.
URL: http://lists.gnu.org/archive/html/bug-bash/2012-08/msg00052.html
BUG=None
TEST=`./image_to_vm.sh --board=x86-alex --from=../build/images/x86-alex/latest` still works
TEST=`rm ../build/images/x86-alex/latest/chromiumos_image.bin && ./image_to_vm.sh --board=x86-alex --from=../build/images/x86-alex/latest/` reports correct line
Change-Id: Iaa7560b4868128119a4f6223b54020611f203635
Reviewed-on: https://gerrit.chromium.org/gerrit/31135
Reviewed-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
This is used to build toolchains with specific env variables
BUG=chromium-os:33240
TEST=trybot x86-generic-toolchain-minor
Change-Id: I2bbdd7d013a15c57c590a0d660a210e0ae2a6695
Reviewed-on: https://gerrit.chromium.org/gerrit/30645
Tested-by: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Zdenek Behan <zbehan@chromium.org>
We don't have anything pulling this into the target, so there is no reason
to list it in package.provided. Further, this messes us up when we we do
want to install it into the target image (for debugging/etc...).
BUG=chromium-os:21330
TEST=`build_packages+build_image` for x86-alex did not install binutils
TEST=`cbuildbot {amd64,arm,x86}-generic-full` did not install binutils
TEST=`emerge-x86-alex binutils` worked
Change-Id: Ie43124a5e763e416508155ab6465a272e639905a
Reviewed-on: https://gerrit.chromium.org/gerrit/30287
Reviewed-by: asharif <asharif@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Otherwise if you switch architectures during the update (32/64-bit), the
module load that's needed to mount the FAT filesystem can't happen (the
module has been replaced with the other binary format).
BUG=none
TEST=run update_kernel on a 32-bit-kernel target after having changed
the overlay to use 64-bit kernel.
Change-Id: I9f302e777a563cbdab2ec636f9a3b35e39ef9c24
Reviewed-on: https://gerrit.chromium.org/gerrit/30681
Tested-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
update_kernel will silently run and report no errors if the user
runs cros_workon_make instead of cros_workon_make --install. As
there are times where the 'uname -a' output doesn't change between
builds (modifying modules or devicetree entries), its not always
obvious that the most recently modified kernel wasn't what was deployed.
This doesn't catch the case where the user first cros_workon's a package
but hasn't done an install (either through emerge or cros_workon_make).
BUG=None
TEST=While cros_workon:
cros_workon_make chromeos-kernel
- observe update_kernel warns
cros_workon_make --install chromeos-kernel
- no warning
cros_workon stop chromeos-kernel
emerge-${BOARD} -g chromeos-kernel
- no warning
emerge-${BOARD} chromeos-kernel
- no warning
Change-Id: I25caa44dc82e00c9bf8703b72d09f76df3db1251
Reviewed-on: https://gerrit.chromium.org/gerrit/30214
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org>
Tested-by: Jon Kliegman <kliegs@chromium.org>
The /var directory on the stateful partition is no longer used in the
recovery image, so there is no reason to mkdir it here.
BUG=chromium-os:32774
TEST=parrot and lumpy recovery image build, manual testing
Change-Id: I9ad936943e88cd2c8cb96a6f715f778c5c65d701
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30488
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Minor code clean up.
BUG=None
TEST=`build_image` still works + boots
Change-Id: I0e26dd3575f963a52d522c4f7c2da8aa5a7dda5c
Reviewed-on: https://gerrit.chromium.org/gerrit/30262
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Rather than forcing all consumers of DEFAULT_BOARD to remember to call
get_default_board, just do it for them automatically.
BUG=None
TEST=`cbuildbot {arm,amd64,x86}-generic-full` works
TEST=`./build_packages --help` shows correct default
Change-Id: I8d6ccb83babb2764a50692318eb9193c45fb3b39
Reviewed-on: https://gerrit.chromium.org/gerrit/17868
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
If an executable was only readable by root, we would skip it with a "Binary
is not user readable" message because the 'file' command was not running as
root. This kept us from generating Breakpad symbols for Xorg, which is now
a top crasher for some boards.
BUG=chrome-os-partner:11791
TEST=Manually ran the script on some files
Change-Id: Id8a13c2968223e54cb1f6c5c3211e9bc2ca89057
Reviewed-on: https://gerrit.chromium.org/gerrit/29839
Tested-by: Michael Krebs <mkrebs@chromium.org>
Reviewed-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Michael Krebs <mkrebs@chromium.org>
Since pkgconfig is installed in the native libdir path, we need to
make sure to filter out all pkgconfig subdirs.
BUG=None
TEST=`./build_image --board=amd64-generic` no longer includes .pc files
Change-Id: Id8116190b6900ac86b433794551b250b6445d9d8
Reviewed-on: https://gerrit.chromium.org/gerrit/29682
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Since we moved the source location during build, some of the security
testcases started reporting errors.
BUG=chromium-os:33392
TEST=build image, check /lib/module/*/{build,source} (none should be there)
Change-Id: I4656f043e4014f33dda03e1f788ba9190e0ce38a
Reviewed-on: https://gerrit.chromium.org/gerrit/29674
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Jim Hebert <jimhebert@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Don't run .bash_logout after invocation of the hook, which clears the
screen, sending unnecessary escape characters.
BUG=None
TEST=Ran locally.
Change-Id: I6c466040e7169d304b892b85be6a5b0d578e7714
Reviewed-on: https://gerrit.chromium.org/gerrit/29645
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Ryan Cui <rcui@chromium.org>
Tested-by: Ryan Cui <rcui@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
We will add more firmware-related tools (static AU programs, updater, netboot
firmware, firmware symbols, firmware for AU testing, ...) into /firmware for
buildbot archiver to output, and should not be picked into target chromiumos
image rootfs; so adding INSTALL_MASK should be the right approach.
BUG=chromium-os:33338
TEST=./build_packages; ./build_image
Change-Id: I64a4477a8ca1a5ed99e32d92767509f21a77c704
Reviewed-on: https://gerrit.chromium.org/gerrit/29411
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
BUG=none
TEST=Build a beaglebone image then verify that the beaglebone
bootloader was installed into the ESP
Change-Id: I1037ee6a61d409e8fd2d66ec6746048a54ce8f14
Reviewed-on: https://gerrit.chromium.org/gerrit/26738
Tested-by: Liam McLoughlin <lmcloughlin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Liam McLoughlin <lmcloughlin@chromium.org>
No need to dump all these mkfs/dd details early on.
BUG=None
TEST=`./build_image` still works, and doesn't spew as much
Change-Id: Ia8113d2ce2c0e6a8a13535b67b37372f0f146398
Reviewed-on: https://gerrit.chromium.org/gerrit/29366
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Make the following commands send stats to chromiumos-build-stats.appspot.com:
build_image
run_chroot_version_hooks
make_chroot
setup_board
update_chroot
BUG=chromium-os:33088
TEST=`cbuildbot --remote -p chromiumos/platform/crosutils alex-paladin`
confirm in the log that uploads succeded, and see them show up in queries
at chromiumos-build-stats.appspot.com.
Change-Id: I0280f91a3e7e0a0483c01c87072bc589003dbe95
Reviewed-on: https://gerrit.chromium.org/gerrit/28969
Tested-by: Matt Tennant <mtennant@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Matt Tennant <mtennant@chromium.org>
Also move the creation of config.txt to common code and add some of the
options that both platform should use to it.
BUG=chrome-os-partner:11403
TEST=build, boot
Change-Id: I9c6eed3bf05c9f0744063c1baf321bf6d24dc9cc
Reviewed-on: https://gerrit.chromium.org/gerrit/28914
Tested-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
We were putting 'vmalloc=234MB' in the command line of all ARM boards
even though that's really board-specific. This shell script really
can't do board-specific stuff, just architecture-specific stuff (and
it would be really hard to change that). ...so we're just going to
remove the vmalloc part and we'll have to add it back in in some other
way.
Note that the vmalloc was only there for tegra2 devices and there is
no active development going on there. See http://crosbug.com/33133
for the task to fix the regression and re-add vmalloc somehow for
tegra boards.
BUG=chromium-os:24808
TEST=Built an image and didn't see vmalloc
Change-Id: I6d45143dec5e7ae1bdd207241d275be261085f90
Reviewed-on: https://gerrit.chromium.org/gerrit/28875
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>
- do test for chromium/src before fixing the checkout.
- don't switch manifests for minilayout users.
BUG=chromium-os:32963
TEST=locally
Change-Id: I1d0cbfc9f4f03d85b34810cdb98d99a7a21d8adf
Reviewed-on: https://gerrit.chromium.org/gerrit/28842
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Ryan Cui <rcui@chromium.org>
Commit-Ready: Ryan Cui <rcui@chromium.org>
BUG=chromium-os:32430
TEST=built dev & test images
Confirmed use flag not normally present, and is
added by mod-for-test to test images.
Change-Id: I1c7f7a6e2f987328c5b9348063b584ff79a3a9df
Reviewed-on: https://gerrit.chromium.org/gerrit/27326
Tested-by: Jim Hebert <jimhebert@chromium.org>
Reviewed-by: Chris Masone <cmasone@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Commit-Ready: Jim Hebert <jimhebert@chromium.org>
See the bug for details.
BUG=chromium-os:32963.
TEST=Locally, remote trybots.
Change-Id: I33f5c42b36f3e06139036c299c2fc2c2ff026411
Reviewed-on: https://gerrit.chromium.org/gerrit/28543
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Ryan Cui <rcui@chromium.org>
Tested-by: Ryan Cui <rcui@chromium.org>
BUG=none
TEST=Ran script, from within chroot, with no args(prompts for password),
one password arg, and multiple args(prints usage and exits), and each time
echo'd the password before it is encrypted. Each time it is correct. From
outside chroot, it only prints an error and exits.
Change-Id: I9380511e8784e4979e664281c751fe6e6defe7ab
Reviewed-on: https://gerrit.chromium.org/gerrit/25397
Tested-by: Isaac Simha <isimha@nvidia.com>
Reviewed-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Isaac Simha <isimha@nvidia.com>
Instead of relying on having autotest tarball in image.zip, this change simply
untars the archived full autotest tarball directly.
BUG=chromium-os:32719
TEST=try job
CQ-DEPEND=I3213180a818617495b347c85b4c97900a47104a6
Change-Id: I398031a19f1291653afe94a52522f5ca79e4f3dc
Reviewed-on: https://gerrit.chromium.org/gerrit/27844
Tested-by: Yu-Ju Hong <yjhong@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Ready: Yu-Ju Hong <yjhong@chromium.org>
/root/.forget_usernames was a hack used historically to facilitate login automation
by reaching to the 'add user' screen directly in test images.
It's not necessary anymore since we can now automate OOBE.
BUG=chromium-os:31807
TEST=suite:bvt
Change-Id: I5384511c0c4630e2c5a71498228d36c151ce52e1
Reviewed-on: https://gerrit.chromium.org/gerrit/27427
Reviewed-by: Chris Masone <cmasone@chromium.org>
Commit-Ready: Nirnimesh <nirnimesh@chromium.org>
Tested-by: Nirnimesh <nirnimesh@chromium.org>
If the kernel panics early during reboot then
the filesystem hasn't been synced yet. This can lead
to corrupted images and other bad things.
BUG=None
TEST=Ran update_kernel, saw sync call run on device
Change-Id: Iea079ba13fef19c1fa30163935d85e4dd5b0f905
Reviewed-on: https://gerrit.chromium.org/gerrit/27288
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org>
Tested-by: Jon Kliegman <kliegs@chromium.org>
This is to transition from a 32bit to 64bit build.
BUG=chrome-os-partner:11058
TEST=build_packages for board=kiev. Verify choot upgraded.
Change-Id: I251be4eba14ba407cfbc6ecf4fb089efe7d457e8
Reviewed-on: https://gerrit.chromium.org/gerrit/26743
Reviewed-by: Dave Parker <dparker@chromium.org>
Tested-by: Dave Parker <dparker@chromium.org>
The new glibc caused a series of problems with Paygen based delta generation.
First, the new glibc is newer than what is used in workstations, or on
the Paygen servers. Since libc wasn't one of the libraries bundled up
by generate_au_zip.py, the executables bundled up (including delta_generator)
would fail because of unstatisfied library requirements at startup.
When the new libc was included by generate_au_zip.py, the delta_generator
executable started causing the dynamic loader to segfault during startup,
presumably because it was linked for a newer version. This means that
the new loader needs to be bundled and explicitly used when invoking
the new executables (thanks David James for figuring this out!).
Next, after including all of the new libraries, bash would crash at startup
with these libraries at the start of LD_LIBRARY_PATH. Since Paygen which
set LD_LIBRARY_PATH before invoking a shell script which invokes the delta
generator, this means delta generation would crash before it started.
If I modified Paygen to not set LD_LIBRARY_PATH, then older au_generator.zip
files could not be properly handled (and we do so regularly).
This change moves the required dynamic libraries into a subdir of the zip
file which will not be in Paygens LD_LIBRARY_PATH which allows bash to
operate correctly.
It also renames each dynamically linked executable from xxx to xxx.wrapped
and creates a shell script named xxx which invokes xxx.wrapped with the
new LD_LIBRARY_PATH and using ld-linux-x86-64.so.2 to do so.
This change also moves a number of constants from inline in various
functions to constants at the top of the script, and introduces a WHITE_LIST
to cause a build failure if ld-linux-x86-64.so.2 isn't present.
(Fixing chromium-os:32550 would help with that)
BUG=chromium-os:32542
TEST=Generated au_generator.zip by hand, extracted files in a test directory,
and generated a delta using Paygen's command line:
LD_LIBRARY_PATH=. PATH=.:$PATH ./cros_generate_update_payload --image ../chromiumos_test_image.bin --output fuzzy --outside_chroot
Change-Id: I90d18a6d17a8f9824b19a6ce480048e388832b56
Reviewed-on: https://gerrit.chromium.org/gerrit/27443
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Don Garrett <dgarrett@chromium.org>
Fix the blacklisting logic, and re-add the magic library linux-vdso.so.
BUG=chromium-os:32542
TEST=Run by hand, .zip contents examined by hand.
Change-Id: I94d99bf62e5eb011ac70428d7cebeaa852519a78
Reviewed-on: https://gerrit.chromium.org/gerrit/27398
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Don Garrett <dgarrett@chromium.org>
Added --remote flag, and some "NonWorkon" methods that complement the "Workon"
methods.
To add a non-workon project to the local_manifest.xml, specify a remote.
The remote tag will be added as part of the new entry in local_manifest.xml.
BUG=chromium-os:32247
TEST=In conjunction with a change in cros_workon, tested that non-workon
projects can be added to the local_manifest.xml.
Change-Id: I1bc4247532647e9bc5962acef988ab57445f4b0e
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/26346
Reviewed-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-by: David James <davidjames@chromium.org>
When trying to cros_workon a non-workon project, supply a remote.
When a remote is supplied, we assume a non-workon project, and add the
remote tag to the local_manifest.xml.
BUG=chromium-os:32247
TEST=Tested that cros_workon start/stop still works for workon package
(I specifically tested with sys-process/ktop), and also tested that this
works with a package that does not match up with a known (i.e. in the
full manifest) package, but is present in the private-overlays. repo
sync pulls the proper source in both cases.
CQ-DEPEND=I1bc4247532647e9bc5962acef988ab57445f4b0e
Change-Id: I03bcf3d42e111e5a0e876763c99b021a14ce7e2e
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/27320
Reviewed-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-by: David James <davidjames@chromium.org>
We were blacklisting some dependant libraries for the delta generator when
we bundle them all up together. When glibc in the chroot was update to be
newer than glibc on our workstations, this broke payload generation.
The real fix is to link delta_generator statically so we don't have to do
this goofy library bundling business (chromium-os:32544). In the mean time,
bundle everything up to get us working again.
BUG=chromium-os:32544
TEST=Trybot run, but not fully verified.
Change-Id: I7b7d247f4edd8ecbab772807f6d2c4e7fdfd414a
Reviewed-on: https://gerrit.chromium.org/gerrit/27327
Commit-Ready: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>
Currently, the scripts in src/scripts have multiple implementations
for handling when common.sh fails to load, some of which are buggy.
To simplify the boilerplate, these scripts now just exit if common.sh
fails to load. The shell itself will print the following message if
common.sh is not found:
/usr/lib/crosutils/common.sh: No such file or directory
BUG=chromium-os:32442
TEST=Run these scripts with and without common.sh installed.
Change-Id: Ie54420b6c649774f9cb039c14c80f4cf6c6ebc07
Reviewed-on: https://gerrit.chromium.org/gerrit/27058
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Commit-Ready: David James <davidjames@chromium.org>
This is necesary since a manifest may have only a subset
of groups turned on- say, minilayout, thus do the check.
BUG=chromium-os:32247,chromium-os:31867,chromium-os:9914
TEST=repo init -g minilayout <usual> && \
./setup_board --board=x86-alex && \
cros_sdk -- cros_workon start chromeos-base/chromeos-chrome
Change-Id: I5320f6419632972671f9082a18725a00517e3f80
Reviewed-on: https://gerrit.chromium.org/gerrit/27062
Commit-Ready: Brian Harring <ferringb@chromium.org>
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
cros_workon belongs in src/scripts because, like other build scripts,
it needs to execute prior to any packages being installed into the
chroot.
This commit imports cros_workon with history. I've also updated cros_workon
to load common.sh from the same directory as cros_workon.
BUG=chromium-os:31952
TEST=Trybot run. Example runs of the script.
Change-Id: I4b13464a1923fbbd0f93efd2356db6a3e428a6a6
Backwards compatible change, because regular variables are addressable
as arrays of up to one item.
BUG=chromium-os:25338
TEST=cros_workon --host start sys-libs/glibc (with local multi-project
mod), and observe that both projects are correctly added to
local_manifest, then repo sync.
TEST=cros_workon start number of single-project ebuilds
Change-Id: Ib3c7ebec7860f23d9331cecd55e3fc9a70709c93
Reviewed-on: https://gerrit.chromium.org/gerrit/23913
Commit-Ready: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
Tested-by: Zdenek Behan <zbehan@chromium.org>
BUG=chromium-os:30384
TEST=install it, run as root, see it fail
Change-Id: Id852af26e2985a86f02212e6c35aeff3324e8b88
Reviewed-on: https://gerrit.chromium.org/gerrit/21857
Commit-Ready: Zdenek Behan <zbehan@chromium.org>
Tested-by: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
There may be multiple ebuilds associated with the same project.
We therefore should not use -u in the sort command here and
eliminate needed ebuilds from the list.
BUG=none
TEST=cros_workon --all --board=x86-generic | grep autotest
(Previously it returned 1 ebuild; now it returns them all.)
Change-Id: I2e33090e2ba06e7cfde908a7e142267fbd74198b
Reviewed-on: https://gerrit.chromium.org/gerrit/19409
Commit-Ready: David James <davidjames@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Calling portageq is fairly slow, so only call it when required, and
combine the multiple calls into a single one. In some cases, we'd
end up calling it multiple times which quickly multiplies the slowness.
BUG=None
TEST=`./cros_workon --board x86-alex start dtc` still works
TEST=`./cros_workon --board x86-alex list` still works and is fast
TEST=`./cros_workon --board x86-alex stop dtc` still works
Change-Id: I6ac6ba283c6529384a7981ad4fffa480bae52234
Reviewed-on: https://gerrit.chromium.org/gerrit/18400
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
The addition of the mask file made the output of "list-all" a little
weird as it includes it as a "board". Filter out all *.mask files
to avoid that.
BUG=None
TEST=`./cros_workon list-all` no longer shows "x86-alex.mask:"
Change-Id: I42c1f6efb53e1d75840c49901c6d2d9edd997fd4
Reviewed-on: https://gerrit.chromium.org/gerrit/18397
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Some of the repos that we search have dirs (like profiles/ and metadata/)
that will never contain ebuilds but do contain a lot of files. Restrict
what find searches for to speed things up a bit.
BUG=None
TEST=`./cros_workon --board x86-alex list --all` shows same list of packages
Change-Id: I09f59f3bb7920a02607cc4595b99ae67c06a18cf
Reviewed-on: https://gerrit.chromium.org/gerrit/18395
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
If you pass an invalid board name, or a board that hasn't yet been setup,
cros_workon will happily create the dirs in /build/ for you. For invalid
boards this isn't a big deal, but for valid ones, this can confuse build
steps later on like ./setup_board.
Change cros_workon to fail immediately if the desired dir under /build/
does not exist. This will "break" using some operations such as "list"
on boards that were installed at one point but currently no longer are,
but cros_workon needs quite a bit more work in order for that workflow
to be supported (if anyone even cares).
BUG=None
TEST=`./cros_workon --board x86-marioffffff list` quit early
Change-Id: Ib83357d5d1c6383987a6d9e3dae1e86cf4864d82
Reviewed-on: https://gerrit.chromium.org/gerrit/18394
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
There's no need to execute `rm -f` directly when `ln -f` will unlink any
existing files for us. One less command to exec.
BUG=None
TEST=`./cros_workon --board x86-alex start metrics` still works
TEST=`./cros_workon --board x86-alex stop metrics` still works
Change-Id: I784d7a215d975a11a8a4a7b5424f4e7f150bf3df
Reviewed-on: https://gerrit.chromium.org/gerrit/18176
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
People who start working on a package and edit the ebuild but accidentally
introduce an error (such as invalid DEPEND) often times don't notice. When
they do `emerge-$BOARD` on that package, portage falls back to the non-live
version automatically. Then developers waste time trying to figure out why
their changes aren't working. Further, emerge doesn't even tell them why
it skipped the live version. The only way to find that out is by doing:
emerge-$BOARD '=foo-9999'
Instead, when someone starts working on a package, automatically mask the
non-live version. That way when they attempt to emerge things, portage
fails immediately with an error message explaining why.
This does make it hard to manually emerge the non-live version like so:
emerge-$BOARD '<foo-9999'
but considering the number of times I've helped people with this behavior
(they added a bug to the 9999 version and couldn't figure it out), that's
a small downside to an otherwise significant improvement. If they really
want to install the non-live version, they can do `cros_workon stop` and
then emerge it.
BUG=chromium-os:27494
TEST=`./cros_workon --board x86-alex start metrics`
`emerge-x86-alex metrics` installs the live version
edit metrics-9999.ebuild to add bogus depend
`emerge-x86-alex metrics` fails explaining error in 9999 version
Change-Id: Ia1843424d771d7dce340a04b27bb164714085520
Reviewed-on: https://gerrit.chromium.org/gerrit/18175
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
The common.sh file has a `sudo_multi` helper to collapse multiple sudo
calls into a single one for a minor speed up. Use it.
BUG=None
TEST=`./cros_workon --board x86-alex start metrics` still works
TEST=`./cros_workon --board x86-alex stop metrics` still works
Change-Id: I4b670a4d4d6f1402a69f1f7129cadc645cc93225
Reviewed-on: https://gerrit.chromium.org/gerrit/18171
Reviewed-by: Chris Wolfe <cwolfe@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
