https://flatpak.org / https://flathub.org I wanted to build a flatpak of kaffeine and publish it on flathub. Then I noticed that libdvbv5 depends on libudev, which is not available in flatpak: https://github.com/flatpak/flatpak/issues/961 On the other hand, mesa/libdrm removed their libudev support and one can access /dev/dri from flatpak without problems. Maybe the same can be done for libdvbv5 (or make it optional). An alternative for cross distro packaging would be AppImage. Not as convenient as Flatpak, but it's able to link against host libraries: https://appimage.org
(In reply to Peter Eszlari from comment #0) > https://flatpak.org / https://flathub.org > > I wanted to build a flatpak of kaffeine and publish it on flathub. Then I > noticed that libdvbv5 depends on libudev, which is not available in flatpak: > > https://github.com/flatpak/flatpak/issues/961 > > On the other hand, mesa/libdrm removed their libudev support and one can > access /dev/dri from flatpak without problems. Maybe the same can be done > for libdvbv5 (or make it optional). > I never used Flatpak/AppImage. If I understand well, you want to generate a package that won't depend on libudev, right? Well, libdvbv5 relies on libudev to discover the devices, although it could be possible to add a patch at v4l-utils that would disable udev, while keepinb libdvb. However, that will also remove some new libdvbv5 features that dynamically discover the Digital TV devices. However, in the case of Kaffeine, our plan is to replace Solid by those new libdvbv5 features for device discovery, as they allows it to detect and use devices connected to a remote machine as well. I have already some patches using this new feature on a devel branch, but support for remote devices there is incomplete. My plan is to work on it during those two weeks. I might eventually work on a way to use libdvbv5 with the new APIs without udev, but not sure how hard would be. Yet, I don't plan to do anything like that any time soon, as I want first to provide support for remote devices on Kaffeine. Yet, if you want to work on such patch, be my guest. One solution that occurred to me would be to force Kaffeine to optionally use a static version of libdvbv5, with something like: diff --git a/CMakeLists.txt b/CMakeLists.txt index 5eea1e096c44..0abd1dc05705 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -11,6 +11,7 @@ set(KAFFEINE_VERSION ${KAFFEINE_MAJOR_VERSION}.${KAFFEINE_MINOR_VERSION}.${KAFFEINE_PATCH_VERSION}${KAFFEINE_EXTRA_VERSION}) option(BUILD_TOOLS "Build the helper tools" OFF) +option(PREFER_STATIC "Prefer static libraries" OFF) # Minimal versions where build is known to work cmake_minimum_required(VERSION 2.8.12) diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index 7ca4bc698331..1fef6328862e 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -52,7 +52,11 @@ target_link_libraries(kaffeine Qt5::Sql Qt5::X11Extras KF5::XmlGui KF5::I18n KF5 KF5::DBusAddons ${X11_Xscreensaver_LIB} ${VLC_LIBRARY}) if(HAVE_DVB) - target_link_libraries(kaffeine ${Libdvbv5_LIBRARIES}) + if (PREFER_STATIC) + target_link_libraries(kaffeine "-lpthread" "-ludev") + STRING(REGEX REPLACE ".so$" ".a" Libdvbv5_LIBRARIES ${Libdvbv5_LIBRARIES}) + endif(PREFER_STATIC) + target_link_libraries(kaffeine ${Libdvbv5_LIBRARIES}) endif(HAVE_DVB) install(TARGETS kaffeine ${INSTALL_TARGETS_DEFAULT_ARGS}) However, the above actually doesn't solve the issue, as, at least on the distributions I use, all based on systemd, libudev is only shipped as a dynamic library. It seems that systemd developers don't like the idea of providing a static library for it. See, for example: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1358372 Btw, that's likely why there aren't any Flatpak for libudev: by design, libudev has to be an exact match of systemd's version. On the bright side, all systemd-based distros should have libudev installed by default, as this is part of systemd-libs package. So, a "distro-independent" package would likely run on all systemd-based distros. > An alternative for cross distro packaging would be AppImage. Not as > convenient as Flatpak, but it's able to link against host libraries: > > https://appimage.org Not sure what should be done at Kaffeine in order to support it, but perhaps the above patch would help, by forcing the usage of static libraries where possible.
> If I understand well, you want to generate a package that won't depend on libudev, right? In the case of flatpak, yes. Flatpak runs the app in a sandbox, where it is not allowed to link against any libraries outside the sandbox (host). All libraries are either bundled with the app or provided by so called "runtimes", which also run in the sandbox. Communication with the host happens through dbus, X11 etc. > Yet, if you want to work on such patch, be my guest. Sorry, but this is way above my programming skills. :) > Not sure what should be done at Kaffeine in order to support it, but perhaps the above patch would help, by forcing the usage of static libraries where possible. No, for AppImage there should be no additional requirements, some just needs to do it. AppImges are just ISO images that get mounted by FUSE under /tmp and executed. They contain most of their dependencies, but not all. In the case of kaffeine one would include Qt, kf5-libs, vlc and libdvbv5, while not including low level stuff like glibc or libudev, but instead link against the libs provided by the host system. A lot of projects already provide AppImages: http://files.kde.org/kdenlive/release/Kdenlive-17.12.0d-x86_64.AppImage https://download.kde.org/stable/kdevelop/5.2.1/bin/linux/KDevelop-5.2.1-x86_64.AppImage https://download.kde.org/stable/krita/3.3.2/krita-3.3.2-x86_64.appimage You just have to chmod +x and ./prog.AppImage, that's all, no installation necessary.
Not to enlarge this scope too much, but Snap, Flatpak, or AppImage, anything would be a better option than what's there now. With Kaffeine being the only KF5-complete video player in Plasma at the moment, a working version is important. BTW I run VLC as a Snap on Neon, and no problems to report there. It just works. I would think that eliminating distro-specific bugs could go a long way to helping push the future development of Kaffeine.
(In reply to James Cain from comment #3) > Not to enlarge this scope too much, but Snap, Flatpak, or AppImage, anything > would be a better option than what's there now. With Kaffeine being the only > KF5-complete video player in Plasma at the moment, a working version is > important. > > BTW I run VLC as a Snap on Neon, and no problems to report there. It just > works. I would think that eliminating distro-specific bugs could go a long > way to helping push the future development of Kaffeine. I'm not against having a snap/flatpak/appimage of it. Just don't have enough time right now to work on it. I'll gladly accept any patches adding support for doing such build. If one prepare a script that generates it in a way that it will run on Fedora 27, I can certainly produce such image for newer Kaffeine versions.
As a test, I uploaded a copy of kaffeine's tree to my github account: https://github.com/mchehab/kaffeine And added a snap/snapcraft.yaml based on vlc snap one there, letting it build automatically. Please notice that my knowledge about snap is minimal. I never even used it myself (nor Flatpack/Appimage). Yet, as the builds are done automatically after a git pull, it sounds easy enough to maintain it. So, I added the neccessary bits for snapcraft to run and produce automatic builds: https://build.snapcraft.io/user/mchehab/kaffeine After a few interactions with the build, I guess it will eventually produce something (still not there yet). However, even with the failed build results, I noticed a major problem with it: the builds are agains the old libvlc version 2.2 with is really too old for Kaffeine, as it doesn't properly support H-264 and H-265 transport streams, with is now used on most places. Only with version 3.0 Kaffeine will work worldwide. Are there any way to make it use vlc 3.0 instead?
Is there any reason not to include version 3 of VLC libs with the snap? I use VLC 3 AS a snap, and it's great. Not sure you can make a snap dependent on another snap, however. One of the main points of snapping apps is to eliminate dependency hell. And it sounds like you're saying vlc 3 is a dependency, so just include the relevant parts (i.e. just the lib parts)? Since snaps are an isolated container, you shouldn't have to worry if a user already has v 2.x installed as it woldn't conflict. I'm sure there are ML and IRC channels you probably can get more precise info; I just wanted to put out there that anything that's a dependency can be included.
(In reply to James Cain from comment #6) > Is there any reason not to include version 3 of VLC libs with the snap? What would be the syntax for doing that? AFAIKT, there's an incompatibility issue on Ubuntu with VLC. So, at least here on one of my test machines, VLC has to be built with: ./configure --enable-chromecast=no > I use VLC 3 AS a snap, and it's great. Not sure you can make a snap dependent > on another snap, however. I don't think there's a way. I guess snapcraft.yaml would need some special syntax in order to make a build-dependency to be built from git instead of installed from an Ubuntu package. > One of the main points of snapping apps is to > eliminate dependency hell. And it sounds like you're saying vlc 3 is a > dependency, so just include the relevant parts (i.e. just the lib parts)? just doing: build-packages: - libvlc-dev Doesn't work, as it will use the old VLC version 2.2. > Since snaps are an isolated container, you shouldn't have to worry if a user > already has v 2.x installed as it woldn't conflict. I'm sure there are ML > and IRC channels you probably can get more precise info; I just wanted to > put out there that anything that's a dependency can be included.
I played a little with snapcraft during the weekend. Doing a basic build itself is not that hard. According to snapcraft, all it would be required is to add a tree at github: https://github.com/mchehab/kaffeine And add a snapcraft.yuml file. If made it right, it were supposed to produce a file that could be installed with: $ sudo snap install --edge kaffeine-player And it would run with: $ kaffeine-player It turns that it is a way more complex than that. Even building fine, the produced exec doesn't work. It seems that it doesn't properly generate a qt5 environment. So, the qt5 SQlite plugin doesn't run at the produced image. I suspect that this is fixable, as I'm pretty sure that this is not the first snap app that would need to use a SQLite database. Yet, I'm not sure if the produced snap will see the /dev/dvb devices or if it would properly access files outside the snap image. Another issue is that snapcraft cleanbuild relies on Ubuntu xenial packages. Those come with libvlc 2.2. Worse than that, building libvlc 3.0 is hard on xenial, as it needs a newer ffmpeg version than what's shipped there. I won't have anytime soon to keep working on it. So, I'll just attach to this BZ the snapcraft.yuml I used on my tests. Eventually, someone with more experience than me with snap could send us patches fixing it and making it work with libvlc 3.0, or, alternatively, send us a patch adding flatpack/appimage builds.
Created attachment 111782 [details] Add snapcraft support to Kaffeine
Git commit 5dda1825c50d8330795ed0ff8b786186acd38c63 by Mauro Carvalho Chehab. Committed on 15/05/2019 at 20:11. Pushed by mauroc into branch 'master'. Add a Dockerfile to allow building Kaffeine inside a container This is a basic Dockerfile with builds Kaffeine inside an Ubuntu Disco container. With the current settings, the container doesn't access the DVB devices with are outside the container. A command that would allow opening a file from your home directory and to use a Digital TV device would be like: $ docker run -it --env="DISPLAY" --env="QT_X11_NO_MITSHM=1" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" --volume="$HOME:$HOME:rw" $(for i in $(ls /dev/dvb/adapter*/*); do echo -n "--device=$i:$i:rwm "; done) kaffeine Please notice, however, that, with the above there won't be any persistent storage. every time the docker container runs, it will forget any previously configured data, EPG information, etc. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> A +46 -0 Dockerfile https://commits.kde.org/kaffeine/5dda1825c50d8330795ed0ff8b786186acd38c63
(In reply to Mauro Carvalho Chehab from comment #10) > Git commit 5dda1825c50d8330795ed0ff8b786186acd38c63 by Mauro Carvalho Chehab. This patch adds container support for Kaffeine. The container itself is easily built by running this from Kaffeine's git: $ docker build -t "kaffeine" . (after having docker properly installed) As explained, however, it has one major drawback: it won't have persistent data, at least if one runs it with: $ docker run -it --env="DISPLAY" --env="QT_X11_NO_MITSHM=1" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" --volume="$HOME:$HOME:rw" $(for i in $(ls /dev/dvb/adapter*/*); do echo -n "--device=$i:$i:rwm "; done) kaffeine I suspect that this can be managed via some docker run command (or by using some high level container tooling), but I need to dig further. So, for now, I'll keep this bug opened.
Kaffeine's Docker container is now at: https://cloud.docker.com/u/maurochehab/repository/docker/maurochehab/kaffeine
Ok, running it should be easy: just install Docker and run: docker pull maurochehab/kaffeine docker run -it --env="DISPLAY" --env="QT_X11_NO_MITSHM=1" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" --volume="$HOME:/home/kaffeine:rw" $(for i in $(ls /dev/dvb/adapter*/*); do echo -n "--device=$i:$i:rwm "; done) maurochehab/kaffeine I'll be pushing a quick set of instructions at the README.md file. With that, I'm closing this BZ.