New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 782211 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 794694
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

kahlee firmware uprev failure

Project Member Reported by sjg@chromium.org, Nov 7 2017

Issue description

Tracking failure of kahlee to uprev firmware in:

https://chrome-internal-review.googlesource.com/497259


Discussion from that CL:

jclinton:

This is the SRC_URI problem again. According to the build logs, chromeos-firmware-kahlee didn't uprev so the SRC_URI couldn't have been recomputed. The only way to get that to happen is to introduce some change to the firmware ebuild. If you bring the chrome-firmware-kahlee ebuild up to date with the ToT version of coral, that will do the trick: https://cs.corp.google.com/chromeos_internal/src/private-overlays/overlay-coral-private/chromeos-base/chromeos-firmware-coral/chromeos-firmware-coral-9999.ebuild

We're going to have to rip out the SRC_URI magic soon; it isn't working.


sjg:

Not so fast!

Even if we did have an insurmountable problem, it would be better to add something like:

# VERSION=1

as a manual version could and require people to increment that in the ebuild each time they change something. That would be no worse than asking people to change various firmware shell variables.

Also, it seems to work fine for coral. I have seen it do a few uprevs without problems.

One thing I notice is that the firmware ebuild is missing these:

inherit cros-unibuild

IUSE="unibuild"

The firmware ebuild does not seem to notice that chromeos-config-bsp has changed. Yet I see that ebuild uprev correctly. It should certainly cause an update to chromeos-firmware-kahlee. Perhaps having the above missing is causing this problem.

I suggest adding the above to the firmware rebuild and trying again.


jclinton:

The uprev logic never uprev's an ebuild for a change in another package's directory or a change in an underlying eclass. Adding any change to the firmware ebuild will cause an uprev temporarily working around the problem until the next time...


 

Comment 1 by sjg@chromium.org, Nov 7 2017

Cc: la...@chromium.org
For reference, here is one of the coral uprevs which succeeded:

https://chrome-internal-review.googlesource.com/c/chromeos/overlays/overlay-coral-private/+/459792

However, looking at the most recent successful firmware uprev, it failed on the coral paladin before it succeeded:

https://chrome-internal-review.googlesource.com/c/chromeos/overlays/overlay-coral-private/+/492672


So in fact there is something wrong here. As a work-around we can modify the firmware ebuild each time, as suggested above. One of the AMD / coreboot ebuilds did things this way. We can require people to do that every time we want to uprev the firmware. It's still better than lots of shell variables in the ebuild.


One option I can think of is to adjust the subdirs to rev, something like this:

CROS_WORKON_REPO="${CROS_GIT_INT_HOST_URL}"
CROS_WORKON_PROJECT="chromeos/overlays/overlay-reef-private"
CROS_WORKON_SUBDIRS_TO_REV=( chromeos-base/chromeos-config-bsp/files )
CROS_WORKON_LOCALNAME=../private-overlays/overlay-reef-private

This means that the firmware packer will not be the workon packages anymore. Probably doesn't matter much except for development of the firmware packer itself.

If we want to be clever then I suppose we could have both:

CROS_WORKON_REPO=( "${CROS_GIT_HOST_URL}" ${CROS_GIT_INT_HOST_URL}" )
CROS_WORKON_PROJECT=( "chromiumos/platform/firmware" "chromeos/overlays/overlay-reef-private" )
CROS_WORKON_SUBDIRS_TO_REV=( . chromeos-base/chromeos-config-bsp/files )
CROS_WORKON_LOCALNAME( firmware ../private-overlays/overlay-reef-private )

Actually, doing:

  CROS_WORKON_PROJECT=( "chromiumos/platform/firmware" "chromeos/overlays/overlay-reef-private/chromeos-base/chromeos-config-bsp"
"chromeos/overlays/overlay-reef-private/chromeos-base/chromeos-firmware-kahlee" )

might yield the result that we're looking for: modifying . We won't know until we try it, though; the uprev logic is too hard to follow.


Comment 3 by sjg@chromium.org, Nov 7 2017

Cc: pbe...@chromium.org yueherngl@chromium.org
Components: OS>Firmware

Comment 5 by sjg@chromium.org, Nov 28 2017

Owner: sjg@chromium.org
Mergedinto: 794694
Status: Duplicate (was: Untriaged)

Sign in to add a comment