Bump Yad to a new release

[Mte90]

Feature Description

The repository used it as fallback, if on the machine yad is not installed, is on readonly since latest december https://github.com/frostworx/steamtinkerlaunch-tweaks/releases
The latest release is from 2021 so is time to find a more viable solution to get yad as fallback.

On v1cont/yad#177 no one proposed another binary and steamtinkerlaunch is an appimage so need that all the dependence are there.

I am getting yad compiled statically without appimage with all the dependencies, in my debian sid and the same executable on a steamos instance without gtk installed.

• Downloading https://github.com/v1cont/yad
• autoreconf -ivf && intltoolize
• ./configure --enable-standalone && make
• Downloading https://github.com/oufm/packelf
• ./packelf.sh ../yad/build/src/yad ./yad

I get a 90~ mb without webgtk and gtkspell support.

I think that just a binary to download in case is not available is more simple then a appimage.

I am thinking to do a CI, that do the binary and the release etc in a personal repository.
In this way it is more easy to maintain and merge this CI to the original yad project.

[Mte90]

Well after an hour I did it https://github.com/Mte90/yad-static-build

So the build is just 13mb, and on steamos and debian sid run (generated from the CI) but I didn't had time to test it with STL.

If someone can help on testing it to see if something is missing as we are ready to switch to a simple binary.

[sonic2kk]

If someone can help on testing it to see if something is missing as we are ready to switch to a simple binary.

Woah, hold on there! I appreciate the work, but sorry, I think we should stick to the AppImage. The reason being is that it will be more broadly compatible. The AppImage isn't just used on SteamOS!

---

I didn't realise Frostworx archived that repo (he's the previous maintainer if you didn't know or see it on the wiki 😉).

It's good to know a static Yad binary does work, but I would rather keep Yad as an AppImage for compatibility.

I think what we should do is transfer the repo over to me and then just update the AppImage release and repo links.

@frostworx could you transfer the tweaks repo to me, and maybe give some hints on how you made the Yad AppImage? Then we can attach a new AppImage release :-)

[frostworx]

sure @sonic2kk
I'll try to find the time tomorrow for the repo transfer.
Can't remember the single s teps, but it was really pretty easy by using kadagos easy builder:

#373 (comment)
#373 (comment)

edit:

"This repository is being transferred to @sonic2kk."

keep up the good work and try not to loose fun working on the project

[sonic2kk]

Repository has been transferred to me and is now unarchived: https://github.com/sonic2kk/steamtinkerlaunch-tweaks

I'll update the links in the code when I'm at home and have some time.

[sonic2kk]

Adjacently related, it seems like YAIURL is duplicated in setYadBin. This should already be defined much earlier on when we set our other URLs. We rely on GHURL being set in setYadBin, and that URL is set in the same place as YAIURL.

I'll take a look at this separately.

[Mte90]

So if you want to run in the appimage you can use the binary I provide in case, maybe we can improve the CI in a way that automatically generate it.
I was thinking to simplify in this way like for the other tools.

[sonic2kk]

I was thinking to simplify in this way like for the other tools.

We use innoextract and cabextract only for SteamOS, and we pull those from the Arch repos. They are only meant to be compatible with Arch and have to be bumped each time the SteamOS version changes to match the newer snapshot.

The Yad AppImage doesn't have this problem, and also is used outside of SteamOS if the user installs it from the commandline. So I'd prefer stick with this packaging.

maybe we can improve the CI in a way that automatically generate it.

Yeah, something like the "Release on Tag" CI I think you proposed for sonic2kk/DumpSteamCollections#2, that might be good if it's possible and doesn't use too much allowance :-) I don't imagine that CI would be run too often though so we could just as easily make a script, run it locally, and attach it in a release.

[Mte90]

Well I think that you can merge as it is, so you can test it and see how works.

Later you can change the rules copying them from the other repo and you are done :-)

[sonic2kk]

Not sure how the whole Docker thing works, but for using https://github.com/kadogo/easy-builder, we can probably just follow the instructions on the Readme to build the AppImage, with one caveat: Modify the easy-builder/yad/build.sh to specifically pull from the Yad 13.0 release commit (v1cont/yad@fbfb0fa). Probably this patch is enough:

diff --git a/yad/build.sh b/yad/build.sh
index 63503c5..8c1b888 100755
--- a/yad/build.sh
+++ b/yad/build.sh
@@ -3,10 +3,14 @@
 # Define GIT repo
 declare -r GIT='https://github.com/v1cont/yad'
 
+COMMIT="fbfb0fafb06fad14b5ddc2d7a9a3064022ee41b4"
+
 # Clone the GIT
 git clone "$GIT" ./git
 cd ./git
 
+git checkout "$COMMIT"
+
 # Build the application
 autoreconf -ivf
 intltoolize

I didn't try as I don't have Docker on my PC, and doing this on a VM might not be great, but if anyone wants to try, with that modification it should be good enough. We don't have to build against the 13.0 release, it might just be a good idea to do so, to match what (up-to-date) distributions are likely to provide.

[Mte90]

Well we can use docker on Github CI too so you can copy part of the CI from https://github.com/Mte90/yad-static-build/blob/main/.github/workflows/build.yaml and a custom https://github.com/kadogo/easy-builder/blob/d80bffe3ab4508667c45c39203e8b5f17e1256c4/goverlay/create-appimage.sh#L15 that automatically do the release.

[sonic2kk]

I'm not against using CI to do it, but it might be a little much for something we can manually do once every so often (probably once a year tops). I also had a little trouble with the Docker approach, it seemed to create an AppImage that wasn't quite the right size and that used a set theme instead of the system theme.

For now, I was able to create a Yad AppImage. I had to hardcode some env var to workaround an upstream LinuxDeploy bug, I think it was NO_STRIP=true to skip stripping the binaries, at the cost of ~20mb bigger AppImage. Unfortunate but not easy-build's fault. I also had to specify the Yad v13.0 commit.

Which brings me to another concern about using CI for this: Right now, easy-build will always pull the latest master, since it just clones. I discussed this upstream and we landed on hardcoding the commit hash to a specific release, and using git checkout in easy-build/yad/build.sh (which does the cloning and compiling, see #373 (comment)). CI would run the build steps, sure, but we wouldn't control the version unless we fork and maybe make it so a commit hash can be taken.

But this all seems like a lot for something that can be done locally and quickly. Maybe some docs on our Yad wiki for building manually with easy-build, or even a readme in its Yad folder, could help for users who want to build the Yad AppImage manually and not download it off the Releases page (people who are very security conscious may do this and that's very reasonable). It just seems to me like this specific case doesn't lend itself as much to CI, since it's more of a manual, occasional thing.

See also: kadogo/easy-builder#17

[Mte90]

My idea of a CI it was to not depends on someone, in a way that it will be always possible to release it a new version.

Do what you prefer anyway, you have all the options :-)

[sonic2kk]

I created a new pre-release Yad AppImage over at sonic2kk/steamtinkerlaunch-tweaks: https://github.com/sonic2kk/steamtinkerlaunch-tweaks/releases/tag/Yad-fbfb0fa-x86_64.AppImage

It seems SteamTinkerLaunch looks for and downloads from the release with the specific name, so right now, it should still be pinned to Yad-8418e37-x86_64.AppImage. This should also mean that updating should be as simple as changing the hash in the YADSTLIMAGE string, as I made sure to name the release and AppImage accordingly on the GitHub Releases side.

I'll do a couple quick checks and then get a draft PR out.

[sonic2kk]

PR is up at #1077, didn't bother making it a draft :-)