linux: Detect unofficial Flatpaks

[mihawk90]

Description

This is a quick and dirty detection that assumes that if a distribution were to package their own Flatpak, they would also use their own custom built runtime (we already have one such example).

A "proper" detection would involve changing how and what OBS logs about the Flatpak environment and use that instead. Since that requires some additional considerations, that is out of scope for now. See obsproject/obs-studio#11788 for work towards that.

As discussed with tytan in #documentation on Discord, we're going with this quick detection until such time that this "proper" detection is ready.

• Depends on linux: Unified system info summary #177. If and when that is merged I will rebase this PR to remove the duplicate commit.
• The help text was adapted from core: Add Detection of unofficial Snap Package #137.

These unofficial Flatpaks are logged as LEVEL_WARNING (analogous to the Snap package). Since this required some changes to make the LEVEL dynamic, I took the liberty of making some minor adjustments to existing checks:

• The unknown Distro, unknown Display Server, and unknown Desktop Environment/Window Manager cases are all now promoted to LEVEL_WARNING too
• removes the emoji warning signs since this is conveyed by the log level now
• removes the Distribution and DE prefixes since they are redundant
• makes adding the line breaks in various locations more consistent by always adding them to the newly concatenated string directly

Motivation and Context

We recently had a user in #linux-support having issues with both their BlackMagic capture card as well as their Nvidia GPU being detected. Upon inspection of the log, tytan noticed this was not our official Flatpak, and it unfortunately also happens to be broken in other ways.

How Has This Been Tested?

#!/bin/bash

echo "===== Unofficial Flatpak ====="
./loganalyzer.py --url "https://obsproject.com/logs/5PhBee18cV5S6MBe"

The second string was tested with the same log, replacing the runtime identifier.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[mihawk90]

Since obsproject/obs-studio#11788 landed we might rethink how this could be done the "proper" way.

We can already grab "valid" commit hashes fairly easily:

# same for `flathub-beta` of course
❯ flatpak remote-info flathub com.obsproject.Studio --log | grep Commit | cut -d: -f2
 4249e4245f75bbec5ad89a4bcfb2726ecbe54c7f3a642e6dbe2820ff4ac2dbc9
 caf0e8d12e2e072b8955a01815fac498746fd8da8de752f6d38a986fd5b21462
 dee53614e7db9461d9e8247db81dfdfda4cdbbdad2d329a522c3946c19cc0386
 bda2690638a8f078c50a9f525e5b8a996c9186e71af1d65ff33fa7396c8de5c3
 a57498baa7462d859465d5ddedb1918b677f4b1306c7613da73c7c49e327dd19
 dc38e67bbca5d6c9c3d005f84bbf006109310de3852a9cd32b1dc19e030b1b0c
 68d5e09141770575d2c962c06dea2bde8c8f97f035a75f6a47b0c1dfd39a7749
 bf9183bb1b4f291037a55df64402ed2dda0a8236907545c1a699ca1b205396fe
 4c452dfbd40bad7156b04449b61eb0bb651456f0848cd7e04c3064aac1ab2e90
 71d974e21fd96594d6ce66314962435a46674e1c441abcc9a6d64cbe5a5f7eda
 9acb8be364db52dcb4ea8ff0b20d63579ecd18d22bd7419deb20a2245356ffd7
 c5bc6eb99d2d638e0892320dd43d0cd5f948d6d90bf786abe2995087a068d131
 e641d66f8f509ff18c1e82bfd6e32e0e0021e56cb01d1471b00f56d82ea8bfa1

Obviously it doesn't really make sense to grab this on every log, but we could write this to a file that is updated either manually or through some CI, that is then read for Flatpak logs.
So the question would be how to do this most efficiently.

[RytoEX]

#177 was merged, so this can be rebased and undrafted. Though, #177 is triggering with Windows logs, so it may need a follow-up.

[mihawk90]

If we still want the "simple" check I can do that, just wanted to make sure we didn't wanna do the "proper" check instead right away.

This check is isolated to isFlatpak(), so the fix for #177 (i.e. either #193 or #194) shouldn't make a difference.

[mihawk90]

Noticed a small issue with a log that was just posted in linux-support:

❯ ./loganalyzer.py --url 'https://obsproject.com/logs/Aq3q70d9H2orswmp'
Critical: 
Warning:  
Info:     No Output Session, Virtual Camera not available, Flatpak | Wayland | DE: COSMIC (COSMIC)

Was still showing Flatpak even though it was supposed to say Unofficial Flatpak.

Fixed that up and because the Log-Level needed to be dynamic for this anyway, I also made it dynamic based on the results of the individual system info checks:

1. Defaults to LOG_INFO
2. Promoted to LOG_WARNING if any of the following are true:
   • is an unofficial Flatpak
   • no Distro detected (missing /etc/os-release)
   • no Display Server detected
   • no Desktop Environment detected

Also cleaned up some inconsistencies with inserted <br>s in the help texts.

[Fenrirthviti]

Please split the formatting changes unrelated to the new additions in to their own commit, but otherwise this seems fine.

[mihawk90]

Split into 3 commits:

• The unofficial Flatpak detection
• Raising loglevels for undefined/warning conditions
• text fixups

For the last one I also decided to drop the "Distribution" and "DE" prefixes. It always bothered me that these two had a prefix while the Display Server didn't. Adding one for the server would make the line even longer for the Discord bot, and they felt pretty redundant since it's obvious what they are anyway.

[Fenrirthviti]

lgtm