As discussed here, Silverblue messes around with the contents of /etc/os-release a bit. They don't seem inclined to change this, so we need to make the test accept their changes; I don't think the changed values constitute a violation of the test case or the release criteria.
/etc/os-release
Right now the test expects "31 (Workstation Edition)" for the VERSION and "Fedora 31 (Workstation Edition)" for the PRETTY_NAME, but the actual values for Silverblue are like "(Fedora) (release).(date).n.(respin)" - e.g. "31.20190926.n.0" - for nightlies, and "(Fedora) (release)_(labelname).(labelmajor).(labelminor)" for candidate composes - e.g. "31_Beta.1.1".
VERSION
PRETTY_NAME
This is all kinds of wacky and not in line with productmd at all, but that's what they're putting in there. Please figure out a way to handle this. I would suggest perhaps using regexes to just ensure the correct release number and edition ident string are in there, rather than trying to check for precisely the weird values they actually put in.
Metadata Update from @adamwill: - Issue assigned to lruzicka - Issue priority set to: High (was: Normal) - Issue tagged with: bug
Ok, I will look at this, as soon as I come back from vacation.
I have taken a look on where do those values originate from and it seems to me, that instead of Fedora 31 they add to it part of the build line. This is easily accessible from the BUILD variable and I will try to parse this using regex to be able to guess the correct value.
Well, no, it's not quite that easy :) I went into quite a lot of detail in the upstream ticket:
The bit added for nightly composes is similar to the compose ID (the BUILD for openQA), but not the same as it. And for candidate composes the bit added is related to the compose label, not the compose ID.
BUILD
Commit 5aa9ca1 fixes this issue
Login to comment on this ticket.