Fabian Vogt <fvogt@suse.de> writes:
Hi,
Am Donnerstag, 1. August 2024, 15:53:59 MESZ schrieb Xu Zhao:
Hello all,
I am the maintainer of telegram-desktop package in OSS and I am seeking advice about how to update the package as its recent change is blocked by openSUSE's openh264 license issue.
2 weeks ago, tg_owt made a commit to use system-level openh264 instead of bundled version (https://github.com/desktop-app/tg_owt/commit/204f1abf4646a77b5c6903bd2cc8501...), this will break the build of telegram-desktop on b.o.o obs because on opensuse openh264 is distributed separately at https://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/x86_64/.
I can think of the following options: 1. patch tg_owt to make openh264 an optional dependency instead of hard dependency, but this will probably be rejected by upsteam and we have to maintain our own patchset. 2. bundle openh264 library with tg_owt and maintain the previous behavior, but I am not sure if this will violate the rules of OBS 3. delete telegram-desktop package on b.o.o (https://build.opensuse.org/package/show/server:messaging/telegram-desktop) and ask users to use the flatpak version 4. if there is a plan to push openh264 into OSS factory, we can keep telegram-desktop and wait until openh264 is available in OSS factory repo.
There are three options:
1. Make the libopenh264 repo available in OBS (definitely technically possible, but can be a pain) 2. Use dlopen on libopenh264.so.* during runtime. That's what libfreerdp and ffmpeg do: https://github.com/FreeRDP/FreeRDP/blob/master/libfreerdp/codec/h264_openh26... https://build.opensuse.org/projects/openSUSE:Factory/packages/ffmpeg-7/files... 3. Build a fake libopenh264 in OBS that is just enough to build against it, but doesn't actually do encoding/decoding.
2 is already used, so probably the best option. Also something upstreamable.
The exact same issue also exits for Electron the recommendation was to add option 2 to it too. It's not so uncommon, especially for cross platform apps.