[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

Mauro Carvalho Chehab  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Mauro Carvalho Chehab  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

--- Comment #12 from Mauro Carvalho Chehab  ---
Kaffeine's Docker container is now at:

https://cloud.docker.com/u/maurochehab/repository/docker/maurochehab/kaffeine

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

Mauro Carvalho Chehab  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Ever confirmed|0   |1
 Status|RESOLVED|REOPENED

--- Comment #11 from Mauro Carvalho Chehab  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

Mauro Carvalho Chehab  changed:

   What|Removed |Added

  Latest Commit||https://commits.kde.org/kaf
   ||feine/5dda1825c50d8330795ed
   ||0ff8b786186acd38c63
 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED

--- Comment #10 from Mauro Carvalho Chehab  ---
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 

A  +46   -0Dockerfile

https://commits.kde.org/kaffeine/5dda1825c50d8330795ed0ff8b786186acd38c63

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

--- Comment #9 from Mauro Carvalho Chehab  ---
Created attachment 111782
  --> https://bugs.kde.org/attachment.cgi?id=111782=edit
Add snapcraft support to Kaffeine

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

--- Comment #8 from Mauro Carvalho Chehab  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

--- Comment #7 from Mauro Carvalho Chehab  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[James Cain]

https://bugs.kde.org/show_bug.cgi?id=388232

--- Comment #6 from James Cain  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

--- Comment #5 from Mauro Carvalho Chehab  ---
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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

--- Comment #4 from Mauro Carvalho Chehab  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[James Cain]

https://bugs.kde.org/show_bug.cgi?id=388232

James Cain  changed:

   What|Removed |Added

 CC||dequ...@mykolab.com

--- Comment #3 from James Cain  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Peter Eszlari]

https://bugs.kde.org/show_bug.cgi?id=388232

--- Comment #2 from Peter Eszlari  ---
> 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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 388232] Provide Flatpak or AppImage for kaffeine

[Mauro Carvalho Chehab]

https://bugs.kde.org/show_bug.cgi?id=388232

--- Comment #1 from Mauro Carvalho Chehab  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.