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>
We start off cros_workon by doing:
touch "${WORKON_FILE}" || die
So we've guaranteed that the user owns this file. As such, there's no
need to go to sudo to update it, so drop that for a minor speed up.
BUG=None
TEST=`./cros_workon --board x86-alex start metrics` still works
TEST=`./cros_workon --board x86-alex stop metrics` still works
Change-Id: I5b78070b85ee53a76b6bdc29e24747b225905368
Reviewed-on: https://gerrit.chromium.org/gerrit/18170
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>
The chromite chrome_set_ver.py script lost its '.py' extension as part
of some recent refactoring. This updates the cros_workon script with
the new name.
BUG=None
TEST=cros_workon start chromeos-chrome no longer reports missing file.
Change-Id: Iae2e88739c4483243581d53daf1ade630e44ab3a
Reviewed-on: https://gerrit.chromium.org/gerrit/17963
Tested-by: Chris Wolfe <cwolfe@chromium.org>
Reviewed-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Chris Wolfe <cwolfe@chromium.org>
The cros_workon script did not support chromeos-chrome in a
minilayout. This appears to result from the usual oddities of
chromeos-chrome and some assumptions in cros_workon's support for
CHROME_ORIGIN=GERRIT_SOURCE.
BUG=None
TEST=Tested on full and minilayout with x86-alex.
cros_workon start and stop succeed, and both equery w and
~/trunk/.config/cros_workon/x86-alex show the correct behavior.
Change-Id: Ic239f08ebedc02e6faea36d54c46ae219bfeb044
Reviewed-on: https://gerrit.chromium.org/gerrit/16995
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Ryan Cui <rcui@chromium.org>
Tested-by: Chris Wolfe <cwolfe@chromium.org>
Commit-Ready: Chris Wolfe <cwolfe@chromium.org>
I find this easier to work with.
BUG=None
TEST=`cros_workon` displays usage now before showing error
TEST=`cros_workon-x86-alex` displays usage now before showing error
Change-Id: Id307bfe34e4aea4b7da62f383bd543ddbef4ccc6
Reviewed-on: https://gerrit.chromium.org/gerrit/15511
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
cros_workon info currently reports warnings about the sort order being
wrong. This is because we're sorting the results in a different order
from what join expects. We should fix that.
BUG=chromium-os:23909
TEST=Verify warnings are gone.
Change-Id: I021a6ac97f3ebd9d0ce0c6350b8c080e4a42977b
Reviewed-on: https://gerrit.chromium.org/gerrit/12596
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Commit-Ready: David James <davidjames@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Because the chromeos-chrome ebuild will no longer force GERRIT_SOURCE,
warn a user that is starting to workon chromeos-chrome that they
may not be getting the experience they expect.
BUG=None
TEST=Ran cros_workon with CHROME_ORIGIN unset, set to GERRIT_SOURCE
and set to LOCAL_SOURCE
Saw warning only on LOCAL_SOURCE
Ran cros_workon start kernel with CHROME_ORIGIN set and saw
no warnings
Change-Id: Iecbc793d3b190a12a126d42a1bfaee6d8846e9ec
Reviewed-on: https://gerrit.chromium.org/gerrit/10815
Tested-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Ryan Cui <rcui@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org>
CL http://gerrit.chromium.org/gerrit/#change,10530 removes dependency of
chrome ebuild on CHROME_ORIGIN being set to GERRIT_SOURCE when user runs
cros_workon. So remove this functionality.
BUG=chromium-os:21969
TEST=Ran cros_workon start/stop for chrome and cros-devutil
Change-Id: I04f7093b45f8e2871f369331bdafbba36443e21d
Reviewed-on: http://gerrit.chromium.org/gerrit/10531
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Ryan Cui <rcui@chromium.org>
Tested-by: Ryan Cui <rcui@chromium.org>
This uses the current directory and gets the project name out of git and
then maps that to the project name(s). In the case of no mapping, it
dies with a message.
Included more changes per review comments by David and Richard.
BUG=chromium-os:20338
TEST=cd src/platform/vpd; cros-workon start .
Change-Id: I6d31d63fe515558286623c177c23fa50a0977b9b
Reviewed-on: http://gerrit.chromium.org/gerrit/7577
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-by: Terry Lambert <tlambert@chromium.org>
Tested-by: Terry Lambert <tlambert@chromium.org>
So that users don't need to run gclient to update depot_tools when they
are developing for chrome in the chroot (i.e., using cros_workon and
emerge), since they don't need to run chrome_set_ver manually.
Developing for chrome outside of the chroot (running 'make' by
themselves) still requires the user to run chrome_set_ver manually after
a repo sync. So they also need to run gclient to get the chrome_set_ver
symlink.
BUG=chromium-os:19112
TEST=ran cros_workon start chromeos-chrome
Change-Id: I93a6db4930ccacfa859d83d8fb19ec45b594dd31
Reviewed-on: http://gerrit.chromium.org/gerrit/6201
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
Tested-by: Ryan Cui <rcui@chromium.org>
When the user cros_workon starts the chrome package for a board, we set
the CHROME_ORIGIN envvar to GERRIT_SOURCE, as part of the new chrome
development workflow. The envvar is set in the
${board}/etc/portage/env/chromeos-base/chromeos-chrome file. We delete
the file when the user runs cros_workon stop for the chrome package.
This change is temporary - GERRIT_SOURCE will eventually become the
default behavior.
BUG=chromium-os:19112
TEST=Verified ebuild behavior for the cros_workon start and stop cases.
Change-Id: I4948383bac3fc4eafc211da2058cbcb24614cedc
Reviewed-on: http://gerrit.chromium.org/gerrit/6049
Reviewed-by: Ryan Cui <rcui@chromium.org>
Tested-by: Ryan Cui <rcui@chromium.org>
repo list is a little faster and is more idiomatic.
BUG=chromium-os:5932, chromium-os:6126
TEST=Make sure cros_workon info --all and cros_workon info kernel still work
Change-Id: I61dfdc8a00669e88b90298f7c990a497b61c174a
Reviewed-on: http://gerrit.chromium.org/gerrit/877
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
Tested-by: David James <davidjames@chromium.org>
BUG=chromium-os:5932, chromium-os:6126
TEST=Run cros_workon --all --host info and cros_workon info --host power_manager kernel
Change-Id: I46849db55d9879cbd65b4400eea9fd6b697e0a10
Reviewed-on: http://gerrit.chromium.org/gerrit/861
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Details
The cros_workong help text has a typographic error of 'commond'
rather than 'command'. This change addresses that issue.
The help text output for the list of commands was also not nicely
aligned, so I've addressed that, too.
Testing
~thutt/g-chroot-execute sudo emerge cros-devutils
After the build & install completed, I executed:
~thutt/scripts/g-workon --help
The output now looks like the following. The typo was on the
'iterate' command.
usage: /usr/bin/cros_workon <command> [flags] [<list of packages>|--all]
commands:
start: Moves an ebuild to live (intended to support development)
stop: Moves an ebuild to stable (use last known good)
list: List of live ebuilds (workon ebuilds if --all)
list-all: List all of the live ebuilds for all setup boards
iterate: For each ebuild, cd to the source dir and run a command
flags:
--board: The board to set package keywords for. (default: '')
--[no]host: Uses the host instead of board (default: false)
--command: The command to be run by forall. (default: 'git status')
--[no]all: Apply to all possible packages for the given command (default: false)
-h,--[no]help: show this help (default: false)
BUG=0
TEST=See above
Review URL: http://codereview.chromium.org/6812022
Change-Id: Idbf9f2cdde1095c310a79740eeef08087c0d415c
Error message not necessary since you already get an error message from bash.
BUG=none
TEST=see below
$ ./cros_workon
./cros_workon: line 13: /usr/lib/crosutils/common.sh: No such file or directory
$ ./cros_workon_make
./cros_workon_make: line 10: /usr/lib/crosutils/common.sh: No such file or directory
Change-Id: I2087d77876376af9ccb497d0a67c354af281c007
R=petkov@chromium.org,anush@chromium.org
Review URL: http://codereview.chromium.org/6726039
Note: this is the moved version of cros_workon
BUG=11507
TEST=./cros_workon --board x86-generic list --all
Change-Id: I4bee245743b4390e1efb634887ea8858c4540f34
Review URL: http://codereview.chromium.org/6368032
Fixes the following issue:
/home/msb/trunk/src/overlays/overlay-x86-generic/make.conf: line 7: prebuilt.conf: No such file or directory
BUG=11513
TEST=Verified that the error goes away.
Change-Id: I5b1dfab55394ba40c02e2a1a2ee7b03a5c4a7941
Review URL: http://codereview.chromium.org/6409031
cros_workon is the only user of cros_workon_common.sh
This is pre-requisite to moving cros_workon into devutils.git
BUG=11507
TEST=Ran ./cros_workon --board x86-generic --all list
Change-Id: I1eab551ab33646360e507328932c151a0d36f50a
Review URL: http://codereview.chromium.org/6347052
Previously, you could not stop working on a package if its ebuild had
been removed. This fixes this issue by skipping canonicalization if the
package name exactly matches a name in the workon file.
BUG=11214
TEST=See below.
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic list
sys-kernel/chromeos-kernel
(cros-chroot) msb@msb ~/trunk/src/scripts $ echo "=foo/bar-9999" >> ~/trunk/.config/cros_workon/x86-generic
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic list
sys-kernel/chromeos-kernel
foo/bar
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic stop foo/bar
!!! No packages matching 'foo/bar'
WARNING: error looking up package foo/bar
ERROR : Error parsing package list
*** I made changes to cros_workon here
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic list
sys-kernel/chromeos-kernel
foo/bar
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic stop foo/bar
INFO : Stopped working on 'foo/bar' for 'x86-generic'
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic list
sys-kernel/chromeos-kernel
Change-Id: Id5cbd2b145b4d0fca96cfb245f1ac99e0b3cbdf3
Review URL: http://codereview.chromium.org/6379006
We stopped using ~ in the workon files many months ago.
BUG=n0ne
TEST=See below.
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic list
sys-kernel/chromeos-kernel
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic start perf
Please run "repo sync" now.
INFO : Started working on 'dev-util/perf' for 'x86-generic'
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic list
sys-kernel/chromeos-kernel
dev-util/perf
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic stop perf
INFO : Stopped working on 'dev-util/perf' for 'x86-generic'
(cros-chroot) msb@msb ~/trunk/src/scripts $ ./cros_workon --board x86-generic list
sys-kernel/chromeos-kernel
Change-Id: I61babd89073d749111be7257b2e8491f07ca52f2
Review URL: http://codereview.chromium.org/6268012
Otherwise, you'll duplicate an entry already in the developers
manifest and cause repo to get confused.
BUG=6898
TEST=Verified that local_manifest gets updated when using minilayout.xml
Verified that the local_manifset does not get updated when not.
Change-Id: I67ffc7004a2267d0d5aaa31570ac2bbeaa8f4f96
Review URL: http://codereview.chromium.org/3468009
If the checkout dir doesn't already exist cros_workon start will print
the wrong dir. Fixed by using readlink -m instead.
BUG=none
TEST=Verified that first start is incorrect without this patch
but is fixed with this patch.
Change-Id: I5db29a8c1737dea1dbe4866e18576f67b9355f84
Review URL: http://codereview.chromium.org/3434008
