RSS Guard searches for plugins in the wrong path

guihkx commented 4 months ago

For reasons unbeknownst to me, the last commit (66ea62889e0e0c8439409365e70e2679c502abc0) completely broke the loading of RSS Guard plugins:

$ flatpak run io.github.martinrotter.rssguard//stable
[...]
time="     1.078" type="debug" -> core: Checking for plugins in '/app/bin/..//app/lib/rssguard'.
[...]

As you can see from the output above, the lookup path of plugins is completely wrong, and causes the "Add new account" dialog from RSS Guard to be completely empty on the first run:

I have no idea how that commit could've possibly caused this, because no part of RSS Guard was touched at all.

Maybe it's a regression introduced by upstream (Freedesktop/KDE SDKs).

Anyway, I have no time to track the root of the issue, so I'll open a pull request soon to try to mitigate the issue.

martinrotter commented 4 months ago

Hm, that is weird, indeed. Even if the rssguard upstream tarball remained the same. But I see you fixed it with manually specifying "CMAKE_INSTALL_LIBDIR" which is weird because its value should be set, as GNUInstallDirs is used within rssguard's cmakelists.txt. Weird.

guihkx commented 4 months ago

Yeah, I'm a bit lost on this one.

And it looks like there hasn't been any recent changes whatsoever in either SDKs.

The good commit (444e229d1005821f04103970eab8b87c403b0afb) prior to the broken one was pushed only 2 weeks ago, and it's still working fine.

We can even downgrade to that build with this command:

$ sudo flatpak update --commit=9a5d3b446f917d56790bfb63cb4000c9a736cbc98c5ad86603e033b62d964985 io.github.martinrotter.rssguard//stable

And on that build, the path of plugins is more sane (i.e. it works):

$ flatpak run io.github.martinrotter.rssguard//stable
[...]
time="     0.843" type="debug" -> core: Checking for plugins in '/app/bin/../lib/rssguard'.
time="     0.852" type="debug" -> core: Plugin '/app/lib/rssguard/librssguard-standard.so' loaded.
time="     0.856" type="debug" -> core: Plugin '/app/lib/rssguard/librssguard-nextcloud.so' loaded.
time="     0.860" type="debug" -> core: Plugin '/app/lib/rssguard/librssguard-greader.so' loaded.
time="     0.864" type="debug" -> core: Plugin '/app/lib/rssguard/librssguard-feedly.so' loaded.
time="     0.868" type="debug" -> core: Plugin '/app/lib/rssguard/librssguard-ttrss.so' loaded.
time="     0.873" type="debug" -> core: Plugin '/app/lib/rssguard/librssguard-gmail.so' loaded.

Additionally, since Flatpak allows us to check the build manifest of any installed app, which contains every git commit hash (or file hash) of every built module (including SDKs), I was able to verify that no changes were introduced in either Freedesktop or KDE SDKs.

Here's the manifest of the "good" version (found in /var/lib/flatpak/app/io.github.martinrotter.rssguard/x86_64/stable/9a5d3b446f917d56790bfb63cb4000c9a736cbc98c5ad86603e033b62d964985/files/manifest.json):

manifest-good.json

And here's the manifest of the "bad" version (found in /var/lib/flatpak/app/io.github.martinrotter.rssguard/x86_64/stable/45be4c0fec138fea08bab9375ee287dc84f4daeadd9a0dc97749d86b0d5e3a62/files/manifest.json):

manifest-bad.json

And if we run diff on these two files, we only see these changes:

diff --git a/manifest-good.json b/manifest-bad.json
index e74e325..fa3531d 100644
--- a/manifest-good.json
+++ b/manifest-bad.json
@@ -84,7 +84,7 @@
           "sources" : [
             {
               "url" : "https://github.com/haasn/libplacebo.git",
-              "commit" : "25ff836306a30e303ea524d1e276a51f2866e7f0",
+              "commit" : "9c4b6bbd7a1e223ffdd61affc4e5d463d42d4345",
               "x-checker-data" : {
                 "type" : "git",
                 "tag-pattern" : "^v([\\d.]+)$"
@@ -105,8 +105,8 @@
               ],
               "sources" : [
                 {
-                  "url" : "https://github.com/KhronosGroup/glslang/archive/14.2.0.tar.gz",
-                  "sha256" : "14a2edbb509cb3e51a9a53e3f5e435dbf5971604b4b833e63e6076e8c0a997b5",
+                  "url" : "https://github.com/KhronosGroup/glslang/archive/14.3.0.tar.gz",
+                  "sha256" : "be6339048e20280938d9cb399fcdd06e04f8654d43e170e8cce5a56c9a754284",
                   "dest-filename" : "glslang.tar.gz",
                   "x-checker-data" : {
                     "type" : "anitya",
@@ -158,8 +158,8 @@
           ],
           "sources" : [
             {
-              "url" : "https://github.com/libass/libass/releases/download/0.17.2/libass-0.17.2.tar.xz",
-              "sha256" : "e8261b51d66ba933fe99248c6fdd8767ed96c5a7e5363c83992c735a2c2fbf74",
+              "url" : "https://github.com/libass/libass/releases/download/0.17.3/libass-0.17.3.tar.xz",
+              "sha256" : "eae425da50f0015c21f7b3a9c7262a910f0218af469e22e2931462fed3c50959",
               "x-checker-data" : {
                 "type" : "anitya",
                 "project-id" : 1560,
@@ -305,5 +305,5 @@
     "--talk-name=org.freedesktop.Notifications",
     "--system-talk-name=org.freedesktop.UPower"
   ],
-  "source-date-epoch" : 1719016423
+  "source-date-epoch" : 1720042611
 }
\ No newline at end of file

Which indicates that literally no part of RSS Guard was touched.

This is baffling. lol

pm4rcin commented 4 months ago

If I'd had to guess myself it could be libplacebo as it had a major version bump as you can see. Try bumping the 2 libraries except this one and I can check. Of course I may be totally wrong as it could be one of the other 2. We have to test it.

guihkx commented 4 months ago

Would that even be possible, though?

If you check the manifest, libplacebo is built as a submodule of the libmpv module, which is also a completely separate module from the rssguard module, where we actually build RSS Guard...

My assumption here is that each module is built isolated from one another, so if that's correct, it'd be impossible for the libplacebo module to somehow affect the build environment of the rssguard module.

guihkx commented 4 months ago

I've closed this through PR #74, but anyone feel free to continue the discussion here if you have an insight on this issue.

pm4rcin commented 4 months ago

Sorry didn't see that the issue was fixed for you by adding flag to cmake. :sweat_smile:

martinrotter commented 4 months ago

The folder /app/bin/..//app/lib/rssguard for loading plugins is constructed in a "static way". The only part of that string which is influenced by build variables is /app/lib. This is value from variable

RSSGUARD_LIBDIR="${CMAKE_INSTALL_LIBDIR}"

So it is in fact value of CMAKE_INSTALL_LIBDIR. It is really weird because that variable usually is just lib or similar. I cannot wrap my head around how it can suddenly be /app/lib.

guihkx commented 4 months ago

Hmm, I think this commit by Flatpak builder is a good candidate as the cause of this issue:

~~https://github.com/flathub/org.flatpak.Builder/commit/5f3c1b86d94e2c60df6e1ac2a178258e40388847~~

EDIT: The issue was actually caused by this recent version bump of flatpak-builder to 1.4.3: https://github.com/flathub/org.flatpak.Builder/commit/12197c39a13cfd611d082231f2b64f741003552f

And this is the flatpak-builder commit that introduced the regression: https://github.com/flatpak/flatpak-builder/commit/8c036e00630e35423c03388aacc06cd00dda74ea

@bbhtt When you have some time, can you please take a look at this?