If we have old dirs (such as a previous migration), we might detect they
need migration for ldso too, but their name isn't a valid board. So skip
those old dirs, and punt old ldso dirs in case they exist (failed previous
upgrade).
BUG=None
TEST=`./update_chroot` moved my old tegra2_kaen and arm-generic boards away, skipped the old softfloat ones, and deleted the previous ldso moves
Change-Id: I9ff316d6de2d9e982f93880426955bb0b49f00a1
Reviewed-on: https://gerrit.chromium.org/gerrit/24890
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Now that glibc installs with the new arm hardfp ldso path, and gcc
generates ELFs with the new path, forcibly migrate existing boards
to the new path by having people rebuild everything.
BUG=None
TEST=`./update_chroot` moved my old tegra2_kaen and arm-generic boards away
Change-Id: I5fee57ff49a9533cc10cb82888014f7cb53033ac
Reviewed-on: https://gerrit.chromium.org/gerrit/24731
Reviewed-by: asharif <asharif@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Right now update_bootloaders.sh occasionally sleeps for 5 seconds if the
developer machine has gvfs-gdu-volume-monitor installed. This sleep was
only necessary because the script pointlessly mounted the device and then
immediately unmounted it, thus triggering a race condition.
In this commit, I've removed the pointless mount/unmount, thus avoiding this
race. This removes the need for the sleep and for retrying the umount.
I also cleaned up the error checking so that failures to cleanup fail
the whole script now.
BUG=none
TEST=Run build_image.sh several times, verify it doesn't sleep for 5 seconds
anymore. Also run remote trybot runs.
Change-Id: Iaa715e9644292f97356a341d17b147be2a5178d9
Reviewed-on: https://gerrit.chromium.org/gerrit/24632
Commit-Ready: David James <davidjames@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Previously, if you were working on a cros_workon package on the host, it
would only get updated once -- after that, the package would never build
again.
With this change, we now rebuild host workon packages any time their
timestamp is modified. This replicates the same feature that we already
have for board packages.
BUG=chromium-os:12771
TEST=Verify that host workon packages are rebuilt when the timestamps change,
and only when the timestamps change.
Change-Id: I31ef1d83dc591161a7cb55c4af806ee4a4212cdd
Reviewed-on: https://gerrit.chromium.org/gerrit/24782
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
BUG=chromium-os:27493
TEST=Verify that packages are only rebuilt when their modification times
change (on either the ebuild or the content).
Change-Id: Iac44e86455d12601a25c8d02f14aa69a4829a330
Reviewed-on: https://gerrit.chromium.org/gerrit/24677
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Rather than having a toolchain package we use for the cross-compilers and
installing a different one for the target build dir, use the same package.
This makes updating more logical as we only have to do it in one place.
BUG=chromium-os:24928
TEST=`cbuildbot amd64-generic-full` works
TEST=`cbuildbot arm-generic-full` works
TEST=`cbuildbot x86-generic-full` works
TEST=build_packages+build_image for x86-alex boots & works
Change-Id: Ib083c3d2eae75d6f5437203990599cdc837dd9dc
Reviewed-on: https://gerrit.chromium.org/gerrit/24722
Reviewed-by: Anush Elangovan <anush@google.com>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
When bootstrapping a chroot, the test for "is this a private source
tree repo" looked under the source tree in ~/trunk/src. That test
was reliable inside the chroot (during update_chroot), but from
outside the chroot (during bootstrapping) it depended on whether the
user had a ~/trunk/src with a certain file.
This change enforces correct behavior outside the chroot regardless
of the contents of the user's home directory.
BUG=chromium-os:31602
TEST=run the test case described in the bug report
Change-Id: I2150347fbad9c84af537f8c572908e6e5ce312b4
Reviewed-on: https://gerrit.chromium.org/gerrit/24659
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The previous upgrade hook didn't change all the perms on files in the host
distdir because the default value expands to a symlink which `find` did not
walk. Add the -H flag to make that happen.
For people who haven't upgraded yet, stub out the existing 38 hook.
BUG=chromium-os:3616
TEST=add a root owned file to host distdir, run ./update_chroot, see file owners fixed
Change-Id: I3f5f88b4fb1d27ce588a342331ad10e957961bcc
Reviewed-on: https://gerrit.chromium.org/gerrit/24459
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Users of other calling scripts that no-op in this scripts are seeing
the warning message incorrectly. Moving this message further down
avoids this issue.
BUG=None
TEST=Visual. Also using to test unified commit queue.
Change-Id: I7bc227f37b26bcedbdb8214286a3f8646ddb610c
Reviewed-on: https://gerrit.chromium.org/gerrit/24369
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: Chris Sosa <sosa@chromium.org>
Commit-Ready: Chris Sosa <sosa@chromium.org>
Now that we're enabling userpriv for the chroot, we need to fix all the
paths that might be owned by root to the right user.
BUG=chromium-os:3616
TEST=`./update_chroot` on a system with root-owned files
in the various paths changed them all to my user
Change-Id: I3655c851d5844524ec77c3476cee7a6e9d70ce0d
CQ-DEPEND=Id513c0b8b380d57dd3e150917a969d0bf36883fc
Reviewed-on: https://gerrit.chromium.org/gerrit/24216
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
BUG=chromium-os:19287
TEST=try building a chroot both using .tbz2, .tar.bz2 and .tar.xz
Change-Id: Idfb13b691201b65c1fa1d5f8597f2aaa401a4051
Reviewed-on: https://gerrit.chromium.org/gerrit/23964
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Zdenek Behan <zbehan@chromium.org>
Tested-by: Zdenek Behan <zbehan@chromium.org>
With the migration to cros_setup_toolchains, we no longer pass down the
versions of binutils/gcc/etc..., so drop the explicit flags.
BUG=chromium-os:23032
TEST=`cbuildbot x86-generic-full` works
Change-Id: I87dbb449e3c413c44cd008fc43d3258a2111227b
Reviewed-on: https://gerrit.chromium.org/gerrit/24056
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Use the ":" builtin command to prevent the increment of $ERROR_COUNT from
ever failing under strict mode (i.e. "set -e").
cros_generate_breakpad_symbols failed for some reason, and this is my best
guess as to the cause. That is, the post-increment would otherwise fail
when $ERROR_COUNT is zero because it would have a non-zero exit status.
BUG=chromium-os:31332
TEST=Manually ran script
Change-Id: Iec7fd9358c339414ccd3c2ca1fd598f124375f0b
Reviewed-on: https://gerrit.chromium.org/gerrit/23979
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Michael Krebs <mkrebs@chromium.org>
Tested-by: Michael Krebs <mkrebs@chromium.org>
For the builders/goobuntu, they're running pbzip2 ~1.0.5 w/ tar 1.22;
for whatever reason, that configuration reproducibly limits to single
core for:
tar -I /usr/bin/pbzip2 -xf /the/sdk
This is annoying; 2 minutes instead of 10s for 48 core builder for
example. Thus does *not* occur w/in the chroot (differing versions),
nor for tar=1.26 w/ pbzip2 1.1.6. The changelogs for both programs
are a bit spartan, but I'm suspecting tar just wasn't feeding it
particularly well (pbzip2 1.0.5 will parallelize if stdin is a pipe).
Regardless, we either try to force everyone to upgrade, or we just
use a form that behaves fine, which is what this CL does.
BUG=chromium-os:31320
TEST=manual validation of it.
Change-Id: I77a434bd2c70873459cbf373192fe73feadb2547
Reviewed-on: https://gerrit.chromium.org/gerrit/23811
Tested-by: Brian Harring <ferringb@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>
We need to rebuild binpkgs that depend on openssl.
Change-Id: I13c59a79700e5704b463b7d03ffbf19d83c5e2e7
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23743
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: David James <davidjames@chromium.org>
We'll phase out later.
BUG=chromium-os:31183
TEST=Ran it.
Change-Id: I7ddf44b661f52ca9186e429ed3955884c4b2cbd4
Reviewed-on: https://gerrit.chromium.org/gerrit/23653
Tested-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Chris Sosa <sosa@chromium.org>
We are about to separate VFAT support from 'initramfs' flag. Let's add
'vfat' flag first so that when this happens nothing gets broken.
BUG=chrome-os-partner:9805
TEST=Build success. Factory install shim still works.
Change-Id: Ia432e3b1a6186f4f7c817a1283c86066ced5fef1
Reviewed-on: https://gerrit.chromium.org/gerrit/23193
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Make shill and flimflam ignore pseudomodem0p on test builds so that
the network devices called pseudomodem0p can be used to test the
cellular classes of shill on virtual machines.
BUG=none
TEST=run network_3GModemControl on a vm
Change-Id: I61cc89d114dcb82bb01b864b68f220fbaf21509d
Reviewed-on: https://gerrit.chromium.org/gerrit/23059
Commit-Ready: Jason Glasgow <jglasgow@chromium.org>
Reviewed-by: Jason Glasgow <jglasgow@chromium.org>
Tested-by: Jason Glasgow <jglasgow@chromium.org>
We need VFAT, ramdisk, and frame buffer console in network boot kernel.
BUG=chrome-os-partner:9805
TEST=Build success. Network boot and install success.
Change-Id: I267f305e2cedf44d002bb1acdf790b4279e20f2c
Reviewed-on: https://gerrit.chromium.org/gerrit/23196
Commit-Ready: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Now that this is part of hard-host-depends, an we don't build the chroot
itself with ccache, so there's no need to force it in early.
BUG=None
TEST=`cbuildbot chromiumos-sdk` passed
Change-Id: I8b7c2a8c6f6df5eedac0c06ebb847f3011eb86d0
Reviewed-on: https://gerrit.chromium.org/gerrit/22954
Reviewed-by: Anush Elangovan <anush@google.com>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Current make_netboot.sh only supports ARM. As we are using network boot
for x86 now, let's fix make_netboot.sh to support both.
BUG=chrome-os-partner:9805
TEST=Generates images and network boot install shim.
Change-Id: Ib445f68255fe8e8a1ee6b7901c9bd67a4a36636d
Reviewed-on: https://gerrit.chromium.org/gerrit/23010
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Running these as root does not make sense. Furthermore, it will fail
on calling cros-workon, which sometimes fails but most certainly will
not give correct information anyway.
BUG=chromium-os:30384
TEST=run build_packages/setup_board with/without sudo
Change-Id: I0cba72334369e35ba0e864c53fd81037ee9e0efa
Reviewed-on: https://gerrit.chromium.org/gerrit/23003
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Zdenek Behan <zbehan@chromium.org>
Tested-by: Zdenek Behan <zbehan@chromium.org>
When bootstrapping for the first time, files in chroot/etc/ might not
exist, so we can't run `find` on them. This manifests itself currently
by spitting out the warning on all initial sdk boots:
find: `.../chroot/etc/resolv.conf': No such file or directory
People can find this confusing and cause sheriffs to waste time on the
wrong thing, so rework the code to avoid this.
BUG=None
TEST=`cros_sdk --delete ; cros_sdk` no longer warns about resolv.conf
Change-Id: I83f892e325e63e682aeb370a9dfc33e284e059d2
Reviewed-on: https://gerrit.chromium.org/gerrit/22845
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Since /etc/mtab could be stale, use /proc/mounts instead.
BUG=None
TEST=`cros_sdk` in diff terminals still works
Change-Id: I526e5173581820c6983fe3702493a0349c1232c3
Reviewed-on: https://gerrit.chromium.org/gerrit/22860
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Resubmit of If62b4f3973f02fd8e1deed35864c824a02ab0c22
This will be safe to land after
I2c4e21ec7e8c0c0cf58947e2b0a3a9edf7617a09
The breakage was a timing issue paired with people not always syncing
the complete tree. No changes to the CL are needed.
It is now used for:
- make_chroot (cros_sdk --bootstrap)
- update_chroot
setup_board is stripped of redundant code which was deprecated by this.
Also stripped is some usepkg logic in make_chroot, as that is now
exclusively source-only.
BUG=chromium-os:23032
TEST=trybot chromiumos-sdk
Change-Id: Ib888cf2886218622d9cfeebb17b9cd4462d06c89
Reviewed-on: https://gerrit.chromium.org/gerrit/22578
Tested-by: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: asharif <asharif@chromium.org>
Commit-Ready: Zdenek Behan <zbehan@chromium.org>
My change in https://gerrit.chromium.org/gerrit/19795 had removed the "set
-e", but https://gerrit.chromium.org/gerrit/17225 re-enabled it --
presumably because that was originally written when the "set -e" was still
there. The strict mode causes the script to exit when sym_upload fails
(which is often).
BUG=chromium-os:30878
TEST=Basic run of script
Change-Id: I2398341505eb9e375f5cb9e008d6c342e4f3b072
Reviewed-on: https://gerrit.chromium.org/gerrit/22617
Commit-Ready: Michael Krebs <mkrebs@chromium.org>
Tested-by: Michael Krebs <mkrebs@chromium.org>
Reviewed-by: Brian Harring <ferringb@chromium.org>
BUG=chromium-os:30820
TEST=Launch incremental buildbots for these overlays and confirm they
are converted to 32bit successfully.
Change-Id: I5ba9294d8b00204110c304a48c0c5f3c0cae9751
Reviewed-on: https://gerrit.chromium.org/gerrit/22497
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Kernel and ramdisk image together are copied into a 16MB partition.
This CL logs their size when building image. If they are larger than
14MB, warning message is emitted. If they reached 16MB, building fails.
BUG=chromium-os:27739
TEST=Build success on x86 and arm.
Check log and see kernel image size logged.
Lower the size limit to 6MB and build x86 factory install shim and
see build fail.
Change-Id: I4c4895c2989b302aa0c3624127518468566d1148
Reviewed-on: https://gerrit.chromium.org/gerrit/22543
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
The "function" keyword is superfluous, not in POSIX, is inconsistent
between bash files, and generally makes me angry. So convert every
instance to the form:
foo() {
BUG=None
TEST=`cbuildbot x86-generic-paladin` works
Change-Id: I97f5ca30a3edfef7222b1e08ac23917dc613b556
Reviewed-on: https://gerrit.chromium.org/gerrit/22467
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Change the kernel loglevel from 1 to 0 to avoid showing console
messages on the screen during shutdown.
An example is the "Power down." message that is shown when shutting
down. This appears on the screen because the kernel prints the
message with KERN_EMERG (level 0). As such, 0 < 1, and the message
appears on the screen.
BUG=chromium-os:28602
TEST=Tested on lumpy, saw no messages when shutting down.
Change-Id: Id3842c2203f6cc4bf3bc9165d8537f440fffba61
Reviewed-on: https://gerrit.chromium.org/gerrit/22104
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Ready: Sean Paul <seanpaul@chromium.org>
Now that the new compiler has been published, there is no need to use
nousepkg anymore. So we can remove this to speed up builds for folks
who are upgrading.
BUG=none
TEST=Remote trybot run to verify tegra2 toolchain is still upgraded
to hardfp.
Change-Id: Iad08114f971c6a9e1a84b1101b25ae60e8822751
Reviewed-on: https://gerrit.chromium.org/gerrit/22406
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
We need to move the old softfp builds out of the way so people can
start working with hardfp.
BUG=None
TEST=`./update_chroot` migrated my few arm boards over
Change-Id: I22429a5f7d80ee20b21ab8a8a77157a46a574fdf
Reviewed-on: https://gerrit.chromium.org/gerrit/22368
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Specifically, do this via env for the time being since each program
doesn't necessarily have an option (nor warrant one).
BUG=None
TEST=None
Change-Id: I26e7f06ad5d6a44a7826bfa8465b34154d21b6a3
Reviewed-on: https://gerrit.chromium.org/gerrit/22295
Tested-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
This actually turns out to be a prime example of amdahls; generating
symbols for just the chrome binary takes ~120s, and with parallelization
in place for my hardware it now takes just over 120s.
For wall time, on my local hardware this brings it down from ~472 to
~120; can't get any faster w/out speeding up dump_syms itself at this
point.
The way this works is via passing the workers pid down a named pipe
once it's finished. The usual approch to bash parallelization is
a round robin loop over an array- this doesn't suffice here due
to the aforementioned chrome binary, thus the hash/control pipe
approach.
For output, we're relying on linux's atomic write gurantee for
pipes; all of our output passes through error/info/warn which
internally will chunk each line of text up into a separate
write (I517ffde4d1bb7e2310a74f5a6455b53ba2dea86c added this).
Via this approach (and the explicit check and setup if necessary
of a pipe), we don't have to worry about interleaved output.
Due to the new approch, we no longer report how much raw data
was generated; instead we report the unique end result. This
is noteworthy since both versions are generating 1742989183 bytes
of data, but the actual ondisk is 1664241402. While that is
78MB of redundant data generated, it's less than 5% of our
generated data and likely is more trouble removing than it's
worth (it won't bring the runtime down at all after all).
Finally... while I realize this is a bit more complex than
most script tricks we do, frankly this route's pretty straightforward-
while we could rewrite this into python, we run the risk of bugs
during conversion, issues w/ multiprocessing having it's own races,
and generally a bit more pain then was worth the hour to hack this
up.
BUG=chromium-os:23050
TEST=cbuildbot x86-generic-full --remote
TEST=manual runs comparing output before/after
Change-Id: I5dd0f685bbb7f5e63e6a1f998e38156b76e80582
Reviewed-on: https://gerrit.chromium.org/gerrit/21940
Commit-Ready: Brian Harring <ferringb@chromium.org>
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
Currently, if set -e spots a nonzero exit we basically have
no real debug information- it just stops immediately without stating
where or why. This forces our scripts to be stupidly verbose so
we can track roughly where they were, thus when they fail we can
use that information to localize the rough exit point.
Instead we should be traping that set -e induced exit and
outputing necessary debug information to run it down. This includes
outputing the relevant stack trace, or at least what we can get of
it.
The 'die' function is now enhanced to automatically dump the trace
that lead to it. For most consumers this is desired- however for
commandline parsing induced dies ("--board is missing" for example),
the trace is noise. For those cases, a 'die_notrace' function was
added that retains the original non-backtrace behaviour.
Example output via instrumenting cros_generate_breakpad_symbols
w/ the failing command '/bin/false' (nonzero exit code).
Before:
./cros_generate_breakpad_symbols monkeys --board=x86-alex
<no output at all, just exit code 1>
With this CL:
./cros_generate_breakpad_symbols monkeys --board=x86-alex
ERROR : script called: ./cros_generate_breakpad_symbols 'monkeys' '--board=x86-alex'
ERROR : Backtrace: (most recent call is last)
ERROR : file cros_generate_breakpad_symbols, line 207, called: main 'monkeys' '--board=x86-alex'
ERROR : file cros_generate_breakpad_symbols, line 163, called: die_err_trap '/bin/false' '1'
ERROR :
ERROR : Command failed:
ERROR : Command '/bin/false' exited with nonzero code: 1
BUG=chromium-os:30598
TEST=inject a failing command into a script, verify the output.
TEST=inject a 'command not found', verify the output
TEST=cbuildbot x86-generic-full --remote
TEST=cbuildbot arm-tegra2-full --remote
TEST=cbuildbot chromiumos-sdk --remote
Change-Id: I517ffde4d1bb7e2310a74f5a6455b53ba2dea86c
Reviewed-on: https://gerrit.chromium.org/gerrit/17225
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>
This allows us to specify a boost size where we know we are growing Chrome,
but don't know what the default sizes are, nor whether we are overriding them
elsewise.
BUG=chromium-os:29829
TEST=try(lumpy-chrome-pfq,lumpy-canary)
Change-Id: I3b7c927874fdfedace027e7a2398d9e97a9d3527
Reviewed-on: https://gerrit.chromium.org/gerrit/21519
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Peter Mayo <petermayo@chromium.org>
Tested-by: Peter Mayo <petermayo@chromium.org>
This is a straightforward change- the intent is to up the debug
information available so we can deal w/ crashes like:
http://chromegw.corp.google.com/i/chromeos/builders/x86-alex32%20canary/builds/56
BUG=None
TEST=# Manual inducing of failures.
Change-Id: Ibea75d1467160fc7f07c21235d701692cec96d05
Reviewed-on: https://gerrit.chromium.org/gerrit/21931
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>
Of the 11713 lines output via this for a mario build, 96% of it
is stating "Using dump_syms.32 for 32-bit file <the-path>".
At one point that may have been useful; now it just obscures errors,
thus only output that info when verbose is turned on.
BUG=None
TEST=./cros_generate_breakpad_symbols; # enjoy the 438 lines of
# output rather than the 11,700 lines of output.
Change-Id: Iba9d1af3421c6b377af8388446521d106399ce25
Reviewed-on: https://gerrit.chromium.org/gerrit/21925
Tested-by: Brian Harring <ferringb@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>
We intended to use some extra python modules for autotest in the chroot,
but decided against it. They're removed from hard-host-depends in
https://gerrit.chromium.org/gerrit/21816
BUG=None
TEST=./upgrade_chroot; see that they've been removed.
CQ-DEPEND=If896436bf9fed7c0fd600ffca9a4c854fd7eceba
CQ-DEPEND=I95df39e40b62c919df0bafcb490d8caa48c04dd4
Change-Id: If9854661b8774d519c5a587e77c31eafdc9b889b
Reviewed-on: https://gerrit.chromium.org/gerrit/21817
Tested-by: Chris Masone <cmasone@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Chris Masone <cmasone@chromium.org>
These shouldn't be around anymore, so let's move them.
BUG=None
TEST=build_packages for x86-alex worked
Change-Id: I95df39e40b62c919df0bafcb490d8caa48c04dd4
Reviewed-on: https://gerrit.chromium.org/gerrit/21806
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Resubmit of If62b4f3973f02fd8e1deed35864c824a02ab0c22
This will be safe to land after I2c4e21ec7e8c0c0cf58947e2b0a3a9edf7617a09
It is now used for:
- make_chroot (cros_sdk --bootstrap)
- update_chroot
setup_board is stripped of redundant code which was deprecated by this.
Also stripped is some usepkg logic in make_chroot, as that is now
exclusively source-only.
BUG=chromium-os:23032
TEST=trybot chromiumos-sdk
Change-Id: Ic908eac712ac097e5c2062d3be70177e172aa924
Reviewed-on: https://gerrit.chromium.org/gerrit/20191
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Zdenek Behan <zbehan@chromium.org>
Tested-by: Zdenek Behan <zbehan@chromium.org>
Using /proc/mounts is safer because mtab may in rare cases get desynced.
The only significant difference in output is "X Y" instead of "X on Y".
BUG=chromium-os:30249
TEST=create a chroot; enter a chroot; exit a chroot
TEST=assortment of manual tests
Change-Id: I392290e6f52a677ee2d77d77e025ef60240b11b5
Reviewed-on: https://gerrit.chromium.org/gerrit/21499
Tested-by: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Zdenek Behan <zbehan@chromium.org>
