#126 Fix VERSION and PRETTY_NAME os-release checks for Silverblue.
Merged 4 years ago by adamwill. Opened 4 years ago by lruzicka.

file modified
+18
@@ -34,6 +34,15 @@ 

          # correct variables to compare the system data with.

          # First, we know the basic stuff

          my $id = get_var("DISTRI"); # Should be "fedora"

+         my $isovar = get_var("ISO"); # Takes the build string for Silverblue variants.

+         # Split the ISO variable at "-" and read fields 4 (release version)

+         # and 5 (the build number).

+         my ($sbver, $sbnum) = (split /-/, $isovar)[4, 5];

+         # Get rid of the ".iso" part of the tag.

+         $sbnum =~ s/\.iso//g;

+         # Now, we merge the fields into one expression to create the correct Silverblue tag

+         # that will contain both the version number and the build number.

+         my $silvertag = "$sbver.$sbnum";

          my $name = ucfirst($id);

          my $version_id = get_var("VERSION"); # Should be the version number or Rawhide.

          my $varstr = spell_version_number($version_id);
@@ -67,8 +76,17 @@ 

          }

  

          my $version = "$version_id ($varstr)";

+         # Version looks differently when the build is a Silverblue. We need to form

+         # a different string here by using the above createad silvertag.

+         if ($subvariant eq "Silverblue") {

+             $version = "$silvertag ($varstr)";

+         }

          my $platform_id = "platform:f$version_id";

          my $pretty = "$name $version_id ($varstr)";

+         # Same problem is when testing the PRETTY_NAME.

+         if ($subvariant eq "Silverblue") {

+             $pretty = "$name $silvertag ($varstr)";

+         }

  

          #Now. we can start testing the real values from the installed system.

          my @fails = ();

This PR fixes #124.
It uses the BUILD variable to get the build string from the
tested compose and uses it to compare correct values for Silverblue.
Originally, it used Workstation values that did not match the
Silveblue ones.

Metadata Update from @lruzicka:
- Pull-request tagged with: bug
- Request assigned

4 years ago

NACK: this will not work for candidate composes. See https://discussion.fedoraproject.org/t/strange-etc-os-release-contents-on-silverblue/2024/17?u=adamwill .

Check the Beta candidate compose test.

You can try and get this right, but you could also just use a bit more permissive of a regex which accepts the expected text plus any other garbage Silverblue sees fit to add...

rebased onto 5aa9ca1

4 years ago

2 new commits added

  • Fix Silveblue Beta Values
  • Fix VERSION and PRETTY_NAME os-release checks for Silverblue.
4 years ago

2 new commits added

  • Fix Silveblue Beta Values
  • Fix VERSION and PRETTY_NAME os-release checks for Silverblue.
4 years ago

Thanks for letting me know, I checked your link and realized that with Beta composes, it puts there a different string. I also realized, that these are probably based on the ISO variable:

  • Fedora-Silverblue-ostree-x86_64-31_Beta-1.1.iso is the ISO variable of the Beta release SB
  • Fedora-Silverblue-ostree-x86_64-31-20191003.n.1.iso is the ISO variable of the nightly build.

When we split this using -, we realize that the version number is either 31 for the nightly or 31_Beta for the Beta, and then that there is the build number. The values, Silverblue puts into the VERSION and PRETTY tags are exactly these values, with a "dot" between them.

I rewrote the code accordingly.

Well, that's probably not quite what's happening, but...it's probably a true enough lie for the present...

looks like it'll work, so let's go with it.

Pull-Request has been merged by adamwill

4 years ago
Metadata