-
Notifications
You must be signed in to change notification settings - Fork 43
helios is unintentionally pinned #8176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I suspect this is some artefact of the incorporation generation stuff that landed recently. Looking at the latest TUF repository built on main (9 hours ago): https://github.com/oxidecomputer/omicron/runs/42323592703 The incorporation locks to osnet-incorporation version:
That lines up with the commit you mention:
The actual latest version of the incorporation in the repository, however, is:
I'm not sure how the new tooling is arriving at an incorporation that contains that older version, but that's what I think we should investigate first. |
Poking briefly at this, it seems like this is where we generate the incorporation: omicron/dev-tools/releng/src/helios.rs Lines 132 to 136 in 69a8d6b
Running this on a machine I have that is pinned to an older Helios, I get:
Notably, that's the version I happen to have installed on that machine:
I would also note that this command is not what I was using to generate the release incorporations earlier. In that case, I was using pkgrepo, which only interacts directly with the repository you name by URL, and does not get confused by locally installed packages or cached catalogues, as it appears that pkg may be doing. The original command was (as appears in
This would, if run now, produce the correct version:
That seems to be the correct latest version that we want:
I suspect we should probably change the releng tool to just do what I had originally been doing in |
NB: If it helps, findver (used above) is: #!/bin/bash
BRANCH=${BRANCH:-master}
want=$1
if [[ -z $want ]]; then
printf 'ERROR: which commit number?\n' >&2
exit 1
fi
#
# Find the current commit depth in this clone:
#
max=$(git rev-list --count "$BRANCH")
if (( want > max )); then
printf 'ERROR: %d is higher than found maximum version %d\n' \
"$want" "$max" >&2
exit 1
fi
(( diameter = max - want ))
found=$(git rev-list --count "$BRANCH~$diameter")
if (( found == want )); then
GIT_PAGER= git log --pretty=fuller -n 1 "$BRANCH~$diameter"
exit 0
fi
#
# If the simple thing doesn't work, it may be because of the craziness of git
# merge commits. Just walk backwards one at a time until we find the one we
# want:
#
# XXX could binary search obviously!
#
for (( diameter = 1; diameter < max; diameter++ )); do
found=$(git rev-list --count "$BRANCH~$diameter")
if (( found == want )); then
GIT_PAGER= git log --pretty=fuller -n 1 "$BRANCH~$diameter"
exit 0
fi
done
printf 'ERROR: could not find version %s\n' "$want" >&2
exit 1 You would run it in a clone of oxidecomputer/illumos-gate that includes an up-to-date stlouis branch. |
I suggested using
|
i wanted to understand what this is to say, in a very immediate sense, it seems more like a docs bug for before putting up #8185 i wanted to make sure that we'd still correctly pin packages if there was an |
looking at a dozen TUFs built from main since #8092 landed, Helios has been at
361574b73e
for all of them, even though commits have been landing on stlouis in the mean time. #8092 includes:but i think we're pinning Helios everywhere by not-design. this has resulted in (i'm sure among other things) a very funny and broken TUF after merging #8160 - what worked in the branch, but depended on newer OS bits, now yields sled panics from the
main
build as it has older and unfixed OS bits. in #8160, commit 7089202's TUF has OS commit25eefe2
from the last few days, but when i pulled main in 8fa48d4, the host OS commit switched back to361574b
where it also is at for builds off of main.The text was updated successfully, but these errors were encountered: