PFQ - AndroidMetadata failed Report failed Failure reason |
||||
Issue descriptionIt happened in all PFQ builders. Link to build or pfq page. https://uberchromegw.corp.google.com/i/chromeos/builders/amd64-generic-chromium-pfq/builds/10183 https://uberchromegw.corp.google.com/i/chromeos/builders/arm-generic-chromium-pfq/builds/3567 https://uberchromegw.corp.google.com/i/chromeos/builders/cyan-chrome-pfq/builds/1237 ... Snippet of log that contains the failure. cmd=['/b/cbuild/chromite/bin/cros_sdk', '--', u'emerge-arm-generic', '-p', '--cols', '--quiet', '--root', '/var/empty', '-e', 'virtual/target-os'], cwd=/b/cbuild Traceback (most recent call last): File "/b/cbuild/chromite/lib/failures_lib.py", line 190, in wrapped_functor return functor(*args, **kwargs) File "/b/cbuild/chromite/cbuildbot/stages/android_stages.py", line 160, in PerformStage versions, branches = self._UpdateBoardDictsForAndroidBuildInfo() File "/b/cbuild/chromite/cbuildbot/stages/android_stages.py", line 134, in _UpdateBoardDictsForAndroidBuildInfo version = self._run.DetermineAndroidVersion(boards=[board]) File "/b/cbuild/chromite/cbuildbot/cbuildbot_run.py", line 936, in FuncWrapper return result(*args, **kwargs) File "/b/cbuild/chromite/cbuildbot/cbuildbot_run.py", line 851, in DetermineAndroidVersion package = self.DetermineAndroidPackage(board) File "/b/cbuild/chromite/cbuildbot/cbuildbot_run.py", line 824, in DetermineAndroidPackage packages = portage_util.GetPackageDependencies(board, 'virtual/target-os') File "/b/cbuild/chromite/lib/portage_util.py", line 1740, in GetPackageDependencies capture_output=True).output.splitlines() File "/b/cbuild/chromite/lib/cros_build_lib.py", line 645, in RunCommand raise RunCommandError(msg, cmd_result) RunCommandError: return code: 1; command: /b/cbuild/chromite/bin/cros_sdk -- emerge-arm-generic -p --cols --quiet --root /var/empty -e virtual/target-os * Generating locale-archive: forcing # of jobs to 1
,
Jun 8 2017
,
Jun 8 2017
Current run already passed AndroidMetadata stage without errors. I wonder what happened in that specific run. In the error log I see: The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by virtual/target-chromium-os-1-r69::chromiumos[vpn] # required by virtual/target-chrome-os-1-r12::chromeos # required by virtual/target-os-1.5-r1::chromeos # required by virtual/target-os (argument) =chromeos-base/vpn-manager-9999 ** I don't understand why 9999 appears here. Does it mean the package was cros-workon'ed?
,
Jun 8 2017
It looks like the change is related to this CL: https://chromium-review.googlesource.com/c/527684/ The problem appears to have resolved itself in the current PFQ run (in progress). I *suspect* that since the CL made a change in both strongswan-5.5.3.ebuild and a dependent change in vpn-manager-9999.ebuild, portage was not smart enough to resolve both in the same CL? This is pure speculation however because my understanding of portage is approximately 0. If the current PFQ run succeeds we can just caulk this up as another mysterious but blessedly brie failure I guess.
,
Jun 9 2017
I see that the vpn-manager uprev was pushed on 6/7, so the change I made in the -9999 ebuild propagated into the -0.0.1-r1835 ebuild. I wonder if the builders tried to build an image that had the updated net-vpn/strongswan package, but used the old -0.0.1-r1834 vpn-manager ebuild that referenced net-misc/strongswan. If that's a problem, maybe in the future, we should let both new and old package names exist concurrently until the -9999 ebuilds referencing the old name have been uprevved.
,
Jun 9 2017
Maybe one reason is that AndroidMetadata stage runs emerge. The stage can run after BuildPackage, then this problem should not appear. I'm trying to merge AndroidMetadata stage into Report stage in Issue 726499. Maybe it can solve this issue too.
,
Jun 9 2017
nya@ - Thanks for that. A similar issue came up recently (emerge failure first detecting in the AndroidMetadata stage which was confusing). Moving this stage until after the ebuild (which presumably would have ran into the same thing?) or merging it with the Report stage would help reduce the confusion a lot. Closing this issue since the PFQ has since cycled green (hooray!). |
||||
►
Sign in to add a comment |
||||
Comment 1 by mojahsu@chromium.org
, Jun 8 2017