Getting log url error on PCSX2 Flatpak builds

[refractionpcsx2]

Hey, did you guys change something recently? Our flatpak builds haven't worked for 3 weeks now, this is the log from the latest actions failure
Any clue what's going on? Do we need to change something, we weren't informed of anything (That I'm aware of), seems to mention something about a missing_build_log_url

Thanks!

Run flathub-infra/flatpak-github-actions/flat-manager@23796715b3dfa4c86ddf50cf29c3cc8b3c82dca8
with:
flat-manager-url: https://hub.flathub.org/
repository: stable
token: ***
verbose: false
/usr/bin/docker exec 1bff1481b93ca79e22fbe4abddaedbf440e45e9147c690b1fba8e8eee729f9f4 sh -c "cat /etc/*release | grep ^ID"
/app/bin/flatpak build-update-repo --generate-static-deltas repo
Updating appstream branch
Generating static deltas
Generating delta: appstream2/x86_64 (488147d230)
Generating delta: app/net.pcsx2.PCSX2/x86_64/stable (703eb07969)
Updating summary
/app/bin/flat-manager-client --token *** create https://hub.flathub.org/ stable
https://hub.flathub.org/api/v1/build/90741
/app/bin/flat-manager-client --token *** push --commit --publish --wait https://hub.flathub.org/api/v1/build/90741 repo
Job failed: {'check_name': 'flathub-hooks', 'build_id': 90741, 'job_id': 155644, 'status': 3, 'status_reason': 'One or more validations failed.', 'results': '{"diagnostics":[{"refstring":"app/net.pcsx2.PCSX2/x86_64/stable","is_warning":false,"category":"missing_build_log_url"}]}'}
Uploading refs to https://hub.flathub.org/api/v1/build/90741: ['screenshots/x86_64', 'app/net.pcsx2.PCSX2/x86_64/stable']
Refs contain 43 metadata objects
Remote missing 21 of those
Has 40 file objects for those
Remote missing 17 of those
Uploading file objects
Uploading 1 files (478628 bytes)
Uploading 1 files (15506738 bytes)
Uploading 15 files (2209846 bytes)
Uploading metadata objects
Uploading 21 files (5630 bytes)
Uploading deltas
app/net.pcsx2.PCSX2/x86_64/stable: 703eb07969cbf822568e214a7fb48011e5b815caa8f9ff1645d88701a6776c4c
Uploading 2 files (4619340 bytes)
Creating ref screenshots/x86_64 with commit cd9973c12db10a861ecf3d99950e7479f9cc6de43a852c6458587022349f9cb9
Creating ref app/net.pcsx2.PCSX2/x86_64/stable with commit 703eb07969cbf822568e214a7fb48011e5b815caa8f9ff1645d88701a6776c4c
Committing build https://hub.flathub.org/api/v1/build/907[41](https://github.com/PCSX2/pcsx2/actions/runs/8335435605/job/22810926952#step:14:42)
Waiting for commit job
Waiting for checks, if any...
Waiting for check: flathub-hooks
/ Job was started
| Running check command
| Check command exited successfully
| Check status updated to Some(Failed("One or more validations failed."))
\ Job completed successfully
\ Check flathub-hooks has failed
Error: Failed to publish the build: Error: The process '/app/bin/flat-manager-client' failed with exit code 1

[bbhtt]

missing_build_log_url

There is your error. You need to pass build-log-url to flat-manager-client create

It should be something like this https://github.com/obsproject/obs-studio/blob/567e35ac693ca0e97e0e74d4f7649fea7501d3ad/.github/workflows/publish.yaml#L148 or a link to the CI pipeline that produced the flatpak package.

[refractionpcsx2]

Okay thanks :) I wonder why it suddenly stopped working..
Oh well, we'll fix our script then, thanks!

[refractionpcsx2]

We have now added it and now the log contains

| Check status updated to Some(ReviewRequired("Some of the changes in this build require review by a moderator."))
and
Api call to https://hub.flathub.org/api/v1/build/92055/purge failed with status 400, details: {'error-type': 'generic-error', 'message': "Can't prune build while in use", 'status': 400}

so I guess we have to wait for you guys :)

Edit: Oh seems to have gone through since our action failed, thanks!

[bbhtt]

That's not a failure, flatpak-github-actions needs to drop the call to purge.

The build got flagged by automatic review, I'll review it soon and then it will be published.

[stenzek]

FYI, we didn't change any permissions, or do anything that would require moderator approval.

If this is due to the SDK changing permissions, then this a very poor design choice. I hit the same thing with duckstation, and having to manually approve potentially hundreds or thousands of packages due to the base image changing seems ridiculous.

Plus, if someone wanted to actually inject malware into a package, having a build log or approval of a manifest isn't going to stop them. So it's just bogging down and making things more difficult for the legitimate users of your service.

The constant changes and breakage for flathub personally make me want to drop our support for it.

[bbhtt]

Actually looks like I already reviewed it

and it is up:

flatpak remote-info flathub net.pcsx2.PCSX2          

PCSX2 - PlayStation 2 Emulator

        ID: net.pcsx2.PCSX2
       Ref: app/net.pcsx2.PCSX2/x86_64/stable
      Arch: x86_64
    Branch: stable
   Version: v1.7.5584
   License: GPL-3.0
Collection: org.flathub.Stable
  Download: 28.5 MB
 Installed: 86.3 MB
   Runtime: org.kde.Platform/x86_64/6.6
       Sdk: org.kde.Sdk/x86_64/6.6

    Commit: f08b31494601a2e072bc7017f32c805a95da2764c65233c44ac4e2c…
    Parent: 44ae08602cbc95ebafab067cd6a2171cd50ce82f48dca6babbbc654…
   Subject: Export net.pcsx2.PCSX2
      Date: 2024-03-23 04:38:44 +0000

[bbhtt]

If this is due to the SDK changing permissions, then this a very poor design choice. I hit the same thing with duckstation, and having to manually approve potentially hundreds of thousands of packages due to the base image changing seems ridiculous.

KDE maintains the SDK and sometimes some permissions are needs to be added/removed. Nothing we can do

Permissions coming from SDK are indistinguishable from the ones in app once merged.

[stenzek]

The paste from above shows that the runtime/sdk is included in the information flathub has. Doesn't seem like a stretch that you could take the difference between permissions from the runtime and the app to determine when the app itself has an addition.

Anyway, not trying to start a flame war, just point out the frustration points, I'm sure we're not the only ones affected.

[bbhtt]

The paste from above shows that the runtime/sdk is included in the information flathub has. Doesn't seem like a stretch that you could take the difference between permissions from the runtime and the app to determine when the app itself has an addition.

An app can add those same permissions in their manifest, there's no way to tell if they come from SDK or from the app manifest, by looking at build metadata.

[bbhtt]

Ideally runtime should not have any static permissions. That's how things are with Freedesktop and GNOME runtimes, but KDE has them because of various reasons so here we are.

[stenzek]

Right. But why does that matter? Every app that uses the SDK is going to include those permissions (which is exactly what happened here), therefore if they're problematic and would be rejected for some reason, then you should reject every app that uses that SDK version. If the set of (app_manifest - sdk_manifest) has changed, then it's something the app developer added.

[bbhtt]

Right. But why does that matter?

The KDE runtime here didn't have the permissions when it was first published, it was later added down the line. In that window apps can add it to their manifest. There's also the matter of maintaining a list of permissions coming from runtime, because they tend to change over time.

therefore if they're problematic and would be rejected for some reason, then you should reject every app that uses that SDK version.

Where did I reject them?

[stenzek]

I didn't suggest that you did. I'm talking about the hypothetical case where you would actually want to reject an update, which I'm assuming is why it triggers a review in the first place. You would want to do the same for every app, for consistency.

Anyway, feels like I'm talking to a wall, so I'm just going to end this here. Won't bother trying to suggest ideas that would save everybody time in the future. :)

[bbhtt]

I'm talking about the hypothetical case where you would actually want to reject an update, which I'm assuming is why it triggers a review in the first place.

The permission changes from SDK only happen once when it gets rebuilt against a newer SDK. Subsequent changes will have only changes from app manifest.

[barthalion]

Hi Connor,

We don’t have a good way to distinguish permissions inherited from the SDK from the ones set by the app. Unfortunately KDE runtime tends to change these relatively often, at least compared to GNOME and freedesktopsdk. It’s not impossible to solve automatically, but there’s always some bigger fish to catch, or fire to put out.

That being said, new builds are rarely held for moderation for longer than a few hours, as we have a fairly good coverage across the time zones, but keep in mind this is all volunteer driven.

The fact the uploads have been failing because of the missing build log URL seems to be my fault, as I was the person informing you about the change and then switching to another action. Apologies about that.

I think the confusion about moderation status comes from the failing purge API call — I will look into making it exit successfully when I’m back from vacation.

The constant changes and breakage for flathub personally make me want to drop our support for it.

Not denying your frustration, but as PCSX2 is one of 4 early adopters bypassing the CI, it’s more exposed to any breaking changes. I’m doing my best to keep everyone informed and builds flowing, but I have only so much mental capacity for this, so some hiccups are inevitable.