search

Martchus / syncthingtray

Tray application and Dolphin/Plasma integration for Syncthing
https://martchus.github.io/syncthingtray/
Other
1.68k stars 44 forks source link

RPM packaging is prone to errors leading to missing ForkAwesome icons #131

Closed b1scu1t closed 2 years ago

b1scu1t commented 2 years ago

Relevant components

Environment and versions

Bug description Icons for both the main windows of the Syncthing Plasmoid and Tray are missing in version 1.1.16. So some buttons will be invisible.

Steps to reproduce

  1. Launch Syncthing Tray / Start Plasmashell
  2. Press icon to expand plasmoid/ show main window.

Expected behavior Icons of the main windows are shown next to the text.

Screenshots The Plasmoid image

The Tray Icon image

Additional context Oddly enough, the icons appear normally in the 'right-click' menu rather than the main window. Also, if I were to downgrade the Syncthing Plasmoid and Tray to version 1.1.6 (also available in the OBS repo), all icons show up normally in main windows.

Martchus commented 2 years ago

Looks like the qtforkawesome icon engine plugin cannot be loaded on your system. It should be provided by the package libqtforkawesome0_0_3 (or libqtforkawesome0_0_4 if you use the VCS repo). The correct package should actually be installed automatically as dependency of syncthingtray or syncthingplasmoid. I did a quick sanity check on the packaging but couldn't find any obvious mistake. So far I also haven't encountered the problem myself under Tumbleweed. (I'm not using Leap myself.)

Martchus commented 2 years ago

Note that you can debug Qt's plugin system via QT_DEBUG_PLUGINS=1. For instance invoking QT_DEBUG_PLUGINS=1 syncthingtray in a terminal on the Arch Linux system I'm currently using prints:

…
QFactoryLoader::QFactoryLoader() looking at "/usr/lib/qt/plugins/iconengines/libqtforkawesomeiconengine-git.so"
Found metadata in lib /usr/lib/qt/plugins/iconengines/libqtforkawesomeiconengine-git.so, metadata=
{
    "IID": "org.qt-project.Qt.QIconEngineFactoryInterface",
    "MetaData": {
        "Keys": [
            "fa"
        ]
    },
    "archreq": 0,
    "className": "ForkAwesomeIconEnginePlugin",
    "debug": false,
    "version": 331520
}

Got keys from plugin meta data ("fa")
…
loaded library "/usr/lib/qt/plugins/iconengines/libqtforkawesomeiconengine-git.so"
…

Under openSUSE you should see similar log messages although the exact paths are different (and should instead match the location of the plugin within the mentioned packages).

b1scu1t commented 2 years ago 
QFactoryLoader::QFactoryLoader() looking at "/usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so"
Found metadata in lib /usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so, metadata=
{
    "IID": "org.qt-project.Qt.QIconEngineFactoryInterface",
    "MetaData": {
        "Keys": [
            "fa"
        ]
    },
    "archreq": 0,
    "className": "ForkAwesomeIconEnginePlugin",
    "debug": false,
    "version": 330752
}
...
loaded library "/usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so"

This is version 1.1.16. Seems like the libraries were loaded, we have similar output. Where did it mess-up...

b1scu1t commented 2 years ago 
QFactoryLoader::QFactoryLoader() looking at "/usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so"
Found metadata in lib /usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so, metadata=
{
    "IID": "org.qt-project.Qt.QIconEngineFactoryInterface",
    "MetaData": {
        "Keys": [
            "fa"
        ]
    },
    "archreq": 0,
    "className": "ForkAwesomeIconEnginePlugin",
    "debug": false,
    "version": 330752
}

Got keys from plugin meta data ("fa")

This is the output for syncthingtray version 1.1.6, but the loaded library "/usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so" line doesn't show up among the loaded libraries anymore. Note that this is the version where the font icons show up correctly.

Martchus commented 2 years ago

When I remember correctly the use of the icon engine was only introduced after 1.1.6. So it is no surprise that it works despite the loaded library ... message not showing up.

Sometimes Qt plugins cannot be loaded because they're built agains a newer version of Qt that currently used. That could happen if you're using my binary repository but only partially upgraded your system.

b1scu1t commented 2 years ago

Sometimes Qt plugins cannot be loaded because they're built agains a newer version of Qt that currently used. That could happen if you're using my binary repository but only partially upgraded your system.

I am using KDE's Qt repos for Leap, so I'm supposed to be running the latest Qt LTS release + KDE's patches (that Arch also uses?). In a sense, my system is 'partially upgraded' as it rolling KDE + Qt over a stable base.

Given you are on Arch, it may be difficult for you to diagnose. It may be a packaging problem indeed.

Martchus commented 2 years ago

So you installed Qt from https://build.opensuse.org/package/show/KDE:Qt:5.15/libqt5-qtbase? It is providing Qt 5.15.2+kde294 which is newer than the official Leap 15.3 repository (which provides 5.12.7¹). That should work as installing a newer version should be ok. However, I still think this is a packaging issue and I really cannot support any third party repos in general.

¹ https://build.opensuse.org/package/view_file/KDE:Qt:5.15/libqt5-qtbase/libqt5-qtbase.spec?expand=1 ² https://build.opensuse.org/package/view_file/openSUSE:Leap:15.3/libqt5-qtbase/libqt5-qtbase.spec?expand=1

Martchus commented 2 years ago

I'm currently updating my Tumbleweed system and was prompted:

3 Dateikonflikte festgestellt:

File /usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so
  from install of
     libqtforkawesome0_0_3-0.0.3-2.4.x86_64 (mkittler)
  conflicts with file from package
     libqtforkawesome0_0_2-0.0.2-2.4.x86_64 (@System)

File /usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so
  from install of
     libqtforkawesome0_0_4-1649182307.78ccb5c-4.2.x86_64 (mkittler:vcs)
  conflicts with file from install of
     libqtforkawesome0_0_3-0.0.3-2.4.x86_64 (mkittler)

File /usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so
  from install of
     libqtforkawesome0_0_4-1649182307.78ccb5c-4.2.x86_64 (mkittler:vcs)
  conflicts with file from package
     libqtforkawesome0_0_2-0.0.2-2.4.x86_64 (@System)

Maybe you encountered such a problem as well? Then you'll have to let it override the file and possibly get rid of the old package to make sure the file on disk is actually the one from the current package. (Not sure how to package this better so one doesn't run into the problem.)

Martchus commented 2 years ago

After the installation everything worked but I wanted to get rid of the old packages so I invoked:

zypper rm libqtforkawesome0_0_3 libqtforkawesome0_0_2 libqtforkawesome0_0_1

Unfortunately that also removed the conflicting icon engine plugin and I was also left without icons until I force-reinstalled it via zypper in -f libqtforkawesome0_0_4.

It would be nice if the old packages would be automatically removed/replaced, e.g. if libqtforkawesome0_0_3 would be removed when libqtforkawesome0_0_4 is installed. Unfortunately I don't know how to improve the packages (https://build.opensuse.org/package/show/home:mkittler/qtforkawesome and https://build.opensuse.org/package/show/home:mkittler:vcs/qtforkawesome).

Of course it is also not ideal that the package containing the versioned library also contains the unversioned plugin. However, both libs are actually tightly coupled and I was actually just copying what official packaging does:

rpm -ql libqtforkawesome0_0_4 libQt5Svg5
/usr/lib64/libqtforkawesome.so.0.0.4
/usr/lib64/qt5/plugins/iconengines
/usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so
/usr/share/licenses/libqtforkawesome0_0_4
/usr/share/licenses/libqtforkawesome0_0_4/LICENSE
/usr/lib64/libQt5Svg.so.5
/usr/lib64/libQt5Svg.so.5.15
/usr/lib64/libQt5Svg.so.5.15.2
/usr/lib64/qt5/plugins
/usr/lib64/qt5/plugins/iconengines
/usr/lib64/qt5/plugins/iconengines/libqsvgicon.so
/usr/lib64/qt5/plugins/imageformats/libqsvg.so
…

And the naming of the library should also be according to the official policy.

(Of course for the official package it is not a problem because the path of the icon engine plugin would be different for Qt 6 and they don't change sonames in the middle.)

Martchus commented 2 years ago

I moved the plugin into its own package (qtforkawesomeiconengine) which should of course be installed automatically as dependency. This should fix the problem with the file conflict. Unfortunately old library-packages will still be kept around. I tried to improve that by obsoleting older packages but it doesn't work as intended.

b1scu1t commented 2 years ago

So you installed Qt from https://build.opensuse.org/package/show/KDE:Qt:5.15/libqt5-qtbase? It is providing Qt 5.15.2+kde294 which is newer than the official Leap 15.3 repository (which provides 5.12.7¹). That should work as installing a newer version should be ok. However, I still think this is a packaging issue and I really cannot support any third party repos in general.

¹ https://build.opensuse.org/package/view_file/KDE:Qt:5.15/libqt5-qtbase/libqt5-qtbase.spec?expand=1 ² https://build.opensuse.org/package/view_file/openSUSE:Leap:15.3/libqt5-qtbase/libqt5-qtbase.spec?expand=1

This is understandable, 3rd-party repos are out-of-scope.

b1scu1t commented 2 years ago

I'm currently updating my Tumbleweed system and was prompted:

3 Dateikonflikte festgestellt:

File /usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so
  from install of
     libqtforkawesome0_0_3-0.0.3-2.4.x86_64 (mkittler)
  conflicts with file from package
     libqtforkawesome0_0_2-0.0.2-2.4.x86_64 (@System)

File /usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so
  from install of
     libqtforkawesome0_0_4-1649182307.78ccb5c-4.2.x86_64 (mkittler:vcs)
  conflicts with file from install of
     libqtforkawesome0_0_3-0.0.3-2.4.x86_64 (mkittler)

File /usr/lib64/qt5/plugins/iconengines/libqtforkawesomeiconengine.so
  from install of
     libqtforkawesome0_0_4-1649182307.78ccb5c-4.2.x86_64 (mkittler:vcs)
  conflicts with file from package
     libqtforkawesome0_0_2-0.0.2-2.4.x86_64 (@System)

Maybe you encountered such a problem as well? Then you'll have to let it override the file and possibly get rid of the old package to make sure the file on disk is actually the one from the current package. (Not sure how to package this better so one doesn't run into the problem.)

Sorry for the late response. Thanks for looking into this!

image

Yeah, got the same problem when I swapped to and from your VCS repository. That's resolved now.

I've linked this to the /r/openSUSE subreddit here: https://old.reddit.com/r/openSUSE/comments/u28eme/requesting_assistance_in_rpm_packaging/?

I'll try to get help from the openSUSE IRC channels a bit later and direct them here.

If https://build.opensuse.org/package/show/KDE:Qt:5.15/libqt5-qtbase is the culprit, you can close the bug as out-of-scope. Would you like to keep it open for packaging feedback?

b1scu1t commented 2 years ago

Oh. The icons are still missing after changing vendors to https://build.opensuse.org/project/show/home:mkittler:vcs and forcefully updating everything. Restarting Plasma has no effect.

Martchus commented 2 years ago

I've already asked on #opensuse-packaging and the best answer I've got so far was to add an additional provide to the packages with versioned name that is not versioned and use that for the obsoletion condition. I haven't had the time to try it yet.

But considering that it still doesn't work for you after you likely cleaned up your system manually and your custom Qt is newer (and not older) I suppose there's still a different issue to be solved in your setup.

And yes, it would make sense to keep this open. I might not be able to help much but I'd be interested to know what the underlying problem is.

Martchus commented 2 years ago

By the way, one easy packaging mistake would be putting the plugin in the wrong directory (and the right directory might differ between Leap and Tumbleweed). I suppose the right directory is where also the SVG icon plugin is located (see command mentioned in https://github.com/Martchus/syncthingtray/issues/131#issuecomment-1094892075=).

Martchus commented 2 years ago

I added the provide/obsolete specification as suggested. That might help. Whether it actually works we'll see on the next Syncthing Tray release.

Martchus commented 2 years ago

I've just noticed that the recent update of boost caused the old boost packages to be deleted automatically (e.g. the packages libboost_filesystem1_78_0 and libboost_filesystem1_78_0-devel are removed in favor of the *1_79_0* packages). I'm wondering how this "magic" works because I don't see any provide/obsolete specifications in https://build.opensuse.org/package/view_file/devel:libraries:c_c++/boost/boost.spec.

Martchus commented 2 years ago

Just for the record, the magic is here: https://build.opensuse.org/package/view_file/openSUSE:Factory/000release-packages/openSUSE-release.spec?expand=1

Martchus commented 2 years ago

Unfortunately it doesn't work, today after updating to 1.1.19 I still had to remove old packages manually:

zypper rm libsyncthingconnector1_1_18 libsyncthingmodel1_1_18 libsyncthingwidgets1_1_18
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...

Die folgenden 3 Pakete werden GELÖSCHT:
  libsyncthingconnector1_1_18 libsyncthingmodel1_1_18 libsyncthingwidgets1_1_18
Martchus commented 2 years ago

Looks like freetype2 isn't build with brotli support on Leap. So there's no support for the woff2 font file I'm using. I've been changing the rpm package to use the ttf font file when building for older distros. I've just tested it under Leap 15.3 and it works.

Unfortunately it also looks like the current version of the Plasmoid doesn't work at all under Leap because it is still at Qt 5.12.7. Considering the Qt Widget based version still works I don't think it is worth putting any further effort into this. Alternatively, when using old stuff like Leap one can also just as well stick to an older version of Syncthing Tray itself.

b1scu1t commented 2 years ago

I've updated to the following packages today from your normal repo: 

libc++utilities5               | 5.14.0-lp153.1.1
libqtforkawesome0_0_4          | 0.0.4-lp153.3.1 
libqtquickforkawesome0_0_4     | 0.0.4-lp153.3.1 
libqtutilities6                | 6.6.1-lp153.1.1 
libsyncthingconnector1_1_19    | 1.1.19-lp153.1.1
libsyncthingmodel1_1_19        | 1.1.19-lp153.1.1
libsyncthingwidgets1_1_19      | 1.1.19-lp153.1.1
qtforkawesomeiconengine        | 0.0.4-lp153.3.1 
syncthingctl                   | 1.1.19-lp153.1.1
syncthingfileitemaction        | 1.1.19-lp153.1.1
syncthingplasmoid              | 1.1.19-lp153.1.1

After the updates and restarting Plasma, all icons work! image

Thank you!

Unfortunately it also looks like the current version of the Plasmoid doesn't work at all under Leap because it is still at Qt 5.12.7.

Have you considered submitting the Syncthing Tray packages to Factory? Packaging (and dependency management) could be delegated to the respective distro maintainers instead.

Martchus commented 2 years ago

Nice. However, note that the Plasmoid only works in your case because you've installed Qt 5.15.x from a devel repo. Otherwise it is completely broken under Leap 15.3.

And yes, I've considered submitting packages (see https://github.com/Martchus/syncthingtray/issues/12). The first dependency c++utilities was already added to a devel project but for the others I've got complaints (e.g. the name was too generic, the style was not as they wanted it, …). I don't find it very motivating to be constrained like this. So I decided against spending more effort on it. Going through the whole submitting procedure for every update is also way too much effort. Of course someone else is always welcome to provide packages but so far nobody did that for openSUSE.

Martchus commented 2 years ago

As the initial problem was fixed I'm closing the issue. I also doubt that the other problems about the RPM packaging can be fixed anytime soon.