droidcam

droidcam copied to clipboard

This application could be packaged and published in various linux package repositories (for example, nixpkgs). But there are several issues that complicate this:

• The lack of versions. Package maintenance relies on them
• A non-standard license. It is strongly advised to use one of OSI approved licenses
• Ad-hoc paths in makefiles (for example, the path to libjpeg_turbo). A better idea is allowing specifying them with environment or make variables.
• The repository structure. Having Makefile in the root it preferable and v4l2loopback-dc should be a separate repo

I extracted v4l2loopback-dc into a separate repo and wrote a package for it. Then I installed it and run DroidCam with https://github.com/aramg/droidcam/issues/47 fix. It worked fine.

To build DroidCam I patched Makefile as with:

diff --git a/linux/Makefile b/linux/Makefile
index 6995c18..28d94a0 100644
--- a/linux/Makefile
+++ b/linux/Makefile
@@ -9,7 +9,7 @@
 CC    = -no-pie
 GTK   = `pkg-config --libs --cflags gtk+-2.0` `pkg-config --libs x11`
 LIBS  = `pkg-config --libs --cflags libswscale libavutil`
-JPEG  = -I/opt/libjpeg-turbo/include /opt/libjpeg-turbo/lib`getconf LONG_BIT`/libturbojpeg.a
+JPEG  = -I"${LIBJPEG_DEV}/include" "${LIBJPEG_OUT}/lib/libturbojpeg.a"
 SRC      = src/connection.c src/decoder.c
 NO_WARN  = -Wno-pointer-to-int-cast -Wno-int-to-pointer-cast

And used the following nix-shell environment:

with import <nixpkgs> {};

let
  libjpeg = libjpeg_turbo.override { enableStatic = true; };
in
  stdenv.mkDerivation rec {
    name = "droidcam";
    buildInputs = [
      gnome2.gtk ffmpeg libjpeg
    ];
    nativeBuildInputs = [ pkgconfig ];

    LIBJPEG_DEV = libjpeg.dev;
    LIBJPEG_OUT = libjpeg.out;
  }

If you fix the packaging related issues I would be glad to properly package the app and create a PR to nixpkgs.

The project has been somewhat intentionally kept out of package management tracks. Primary reason, those (some, maybe all) will inevitably get outdated and I don't want to be the one to be maintaining them.

Your fork provides a nix pkg. I've never heard of nixpkgs. From what I can tell, most of my users are either on Ubuntu on Arch. What about an Ubuntu PPA, or an AUR? Those would be more useful. Who's going to make and maintain those? I've seen lots of Fedora users. Whats the pkg management system for Fedora? Do we also need an RPM package?

As far as I know there is already an AUR. I don't know how up to date it is. There used to be an PPA, it quickly did become outdated and I started to get hit with support requests asking why the app isn't working.

The current distribution method is completely distro agnostic, I prefer to keep that variable out of the equation. 10 years ago Ubuntu was everywhere. Now Arch has a ton of users. Tomorrow it might be nixOs.

There is a dead-simple update check built into the Windows client, which I'll likely port here once the Linux client gets a few more features. So if you'd really like to contribute, #1 and #38 would help us get there.

Primary reason, those (some, maybe all) will inevitably get outdated and I don't want to be the one to be maintaining them.

For nixpkgs there's a bot which creates a PR if there's a fresh github release. So it's super easy to keep things up to date.

I don't know if there's such a technology available for other package repositories though.

As far as I know there is already an AUR. I don't know how up to date it is.

It would be easier to tell if there were actual versions on github.

The current distribution method is completely distro agnostic

Not quite, it's very FHS dependent. That's why I had to modify the makefiles to build and run it.

I'll definitely begin to tag and upload releases here on Github, now that the project has more activity.

Regarding the last comment, thats the thing, build+run != package and release. The binaries are distributed pre-compiled, by me, since I don't want to deal with all the different package management systems.

If you want to compile and play with the code, thats fine. As-is it should be very easy to appropriate for your distro. What did you have to change in the makefile? If there's anything in the readme that could be improved, just let me know.

Regarding the last comment, thats the thing, build+run != package and release.

Well, in source-based distros, a packages is just a description which source to take and how to compile it. For example, droidcam in AUR is just this file: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=droidcam

Pre-compiled packages are more suitable for binary-based distros.

What did you have to change in the makefile?

For v4l2loopback-dc I made the following change: https://github.com/suhr/v4l2loopback-dc/commit/2985993902fb122bf3eeaeced4b6759775c33bd6

Having KERNEL_DIR option is important: there's no /lib/modules/`uname -r`/build in NixOS.

For droidcam, see the patch in the top post. Again, LIBJPEG_DEV and LIBJPEG_OUT are important: there's no /opt/libjpeg-turbo in NixOS. And of course, you can have fallback paths just like with KERNEL_DIR.

NixOS is very opinionated about paths because separation of artifacts allows reproducible builds. So everything lives in paths like /nix/store/dllmzgmgj4i9icbngk1blxaszq7jd1kl-linux-5.4.35 and doesn't interfere with each other.

PS: I made a bug in the Makefile for v4l2loopback-dc: there should be just M=$(PWD) clean. It didn't really matter anyway because I have not called make clean.

All your change does is add the word "modules" to the make line, and change from back-ticks to $(). Or am I missing something? edit: Ok, I see KERNEL_DIR is an optional env variable, thats fair enough.

There's no /opt/libjpeg-turbo on any distro, as mentioned in the README this is a custom download + install.

If nixOS wants to be opinionated about paths, thats fantastic and good for them. Another great example of why I don't want to deal with specific distros and am keeping things generic and follow my own packaging and release process.

Added a standard licence for the code. If you'd like to open a PR for the v4l2loopback Makefile changes, I can accept that.

As far as packaging, I'd prefer not to have the client packaged and re-distributed due to lack of consistency across distors.

Let me know if you any other comments.

Leaving this here to hopefully avoid dups in the future.

The current distribution method is completely distro agnostic, I prefer to keep that variable out of the equation. 10 years ago Ubuntu was everywhere. Now Arch has a ton of users. Tomorrow it might be nixOs.

Have you thought about Flatpaks, AppImages or Snaps? Thay are distro agnostic and can be easily installed and updated.

@serovar all of those work for the client portion (read: user space) of this, but honestly the client portion is unlikely to be the biggest area where users struggle.

Do anyone have this project packaged for nixos to use with a nix-shell?

I am tying to use https://github.com/suhr/nur-packages/blob/master/pkgs/v4l2loopback-dc/default.nix But Not able to use it wit nix shell :

➜  nur nix-shell                                                                                                                                                                ~/fun/nix/nur
error: cannot auto-call a function that has an argument without a default value ('stdenv')

How do you use it? nix-shell -p nur.repos.suhr.v4l2loopback-dc seems to work fine.

Anyway, it is probably not very useful to install kernel drivers in nix-shell.

@aramg I am trying to make a PPA for Droidcam using a modified version of this code (which was based on the original debian source package by Paolo Rotolo). Right now, it does not use DKMS.

I want to use dkms in the deb package, so that the user won't have to reinstall droidcam after updating the kernel.

I wanted to know if install has to be executed even after calling install-dkms. Will only install-dkms be sufficient? Or do I have to execute install as well (then in which order should these two scripts be executed?)

Also, if I want to enable sound (along with dkms), in which order should install-sound, install and install-dkms be executed?

I have tested the PPA in my computer, it would be great if anyone else tests it. I would eventually like to provide .deb package for Raspberry Pi in the PPA (I will have to build the armhf binaries of droidcam and droidcam-cli for that), but right now the package is only for amd64.

Known Issues: The .deb package from the PPA fails to install in Kernel 5.4, but this is a consequence of #89.

To follow up on my comment in #89, since you're not sure how install/install-dkms/install-sound work, I'd ask that you please not distribute a PPA. I really do appreciate the initiative and wanting to help, but I'm against 3rd party packages in general. Until there is an official v4l2 loopback driver in Linux, like ALSA Loopback, this is going to be a pain.

If I get a chance, I'll update the Linux client to use the existing v4l2loopback driver which is already packaged in most distros these days, and then we can talk about packaging droidcam too.

My intention to build the ppa was to eventually distribute packages for Raspberry Pi (where there is no internal webcam or microphone, and it is a pain to build the package from source in Pi. The recent amd64 build was only to test). From the number of forks of paolorotolo/droidcam one can see that many people tried to build the .deb package (and maybe they used their own .deb packages), but not every user can do that, so I wanted to share my package.

It's true that I don't understand very well how the install/install-dkms/install-sound scripts work, but the .deb package will only run these scripts during installation (and create a .desktop file for the client), so if the scripts work correctly, and they are executed in the correct order, it should work correctly (#89 is not due to PPA or .deb package. Someone reported that kernel 5.4 works, there must be some issue with my system). I could trial and error to figure out the order of execution of scripts when dkms is used, but I thought I can directly ask you here.

I can understand your problem of handling much more support requests (and why a program like droidcam can have lots of issues with third party packaging if not packaged correctly, unlike a simple python program). As a workaround, you could make a GitHub Issue template, where you can ask users to first install from .zip, and if the problem persists, only then open an issue (and any third party method of installation are unsupported, and the issue will be closed immediately in such cases). Users can instead report debian packaging related issues to this repo. Update: I found this, and will run more tests. https://github.com/aramg/droidcam/blob/master/linux/README-DKMS.md

It is easy to update the PPA at this point (update .zip file, change version number, upload to Launchpad). If your objection is due to fact that the PPA can soon be out of date (like the previous PPA did), I assure you that I would like to maintain the PPA (I have been maintaining some other PPAs for some time, which have thousands of users according to ppa-stats).

3rd party packages would make it much more convenient for end users to get a working copy of the program. Also, most Raspberry Pis run the same OS, and have almost same hardware, so if the package works, it should work in all Raspberry Pis running Raspbian.

I am not publicizing the PPA anywhere else, I posted here for testing and feedback. Of course, if you still insist against the PPA, I won't press the issue further. If you want to wait till droidcam client is rewritten to use the existing v4l2loopback driver in distros, that's also fine.

Would you be more comfortable with distros packaging this if they included a disclaimer like

I agree that packaging would be very useful in some distro such as NixOs for which the manual install just don't work. What's wrong with writting a disclamer as proposed by @jtojnar ?

I agree that packaging would be very useful in some distro such as NixOs for which the manual install just don't work. What's wrong with writting a disclamer as proposed by @jtojnar ?

Whats the issue on NixOS? Can the current install script be updated to fix it?

I am fine with the disclaimer.

On Linux systems, it not inappropriate to install anything by running random scripts. If you do that, you will soon have file system full of files, which you have no idea where they came from or which version they are, just like on Windows. This is why every distribution will strongly suggest to use packages and even to create your own when none are available.

The main thing a package maintainer does is build and install a project into an empty directory tree (e.g. chroot) to see what files the package creates and then create an archive with those files. Users will then install the contents of the archive using package manager. The package manager typically tracks which files come from which package, which it can only do by controlling what gets copied. Install script that installs to live file system would bypass this process, thus leave the file system in an unknown state.

Of course projects cannot be expected to create packages for every Linux distribution, that is where package maintainers come. They should ensure that everything is up to date and working, which is easier and less-error prone when they can use provided installation script (e.g. make && make install) that just installs the files to specified directory for as much of the package as possible.

Fortunately, the Makefiles mostly work if we pass JPEG=$(pkg-config --libs --cflags libturbojpeg) to make. It would just be very much preferred if we did not have to do that, which is why I opened https://github.com/aramg/droidcam/pull/102. Well, and also since 1.5, icon needs to be installed, which requires more manual work – this is what I am currently using for my personal package https://github.com/jtojnar/nur-packages/blob/06b1bf241dffa4d4f8e93dd059b31e06438a7ae7/pkgs/droidcam/default.nix#L31-L47 and I would be very happy to provide a patch that would allow me and other distros to just use make && make install PREFIX=... to create the package.

The main reason why we did not include the package into NixOS so far, though, is your opposition to distribution packaging. We do not want any bad blood between our projects, which is why I want to establish some trust and alleviate your concerns first.

As I understand it, your main objections are that

1. distributions ship old versions of software and that
2. distributions ship configurations you could not have tested and thus cannot support.

For the first point, I subscribe to changes of all projects I maintain and am typically able to update the package within few days of a release. For leaf packages like droidcam would be, I often make an update within hours. Then it might take few more hours to days (depending on how busy the build infrastructure is) for the repository to be updated and users to start using the new version. I can also promise to remove the package if I am no longer able to maintain it.

For the second point, hopefully the disclaimer will succeed in reducing the number of people who come here for support.

The reason why packaging is so important for NixOS is it is not an FHS distro. Instead is stores everything in paths like /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/. It allows to have a reproducible environment.

OK, I think you guys should just go ahead and package the app for nixOS then. Up until this year the app was much less popular, but with the increased popularity, moving towards a more standard deployment architecture makes sense and something I've written down as a todo.

I noticed some other projects provide eg. an official Ubuntu package and other distros maintain their own releases which users are directed to follow up on in issues. And like I mentioned earlier, v4l2loopback is a lot more widely available and the need for droidcams own version is not there anymore.

something something something ... I think i'll do a package for every distro...

eh, just do a flatpak and move on with your life.

Any update? Flatpak is becoming the standard everywhere.

A flatpak would be amazing!

One of the main reasons flatpak exists is exactly what you complained about... it provides one package format to work on any distro.

It's also the only way (apart from maybe AppImages) to install apps on distros such as SteamOS and Fedora Silverblue.

Please, please provide a flatpak! I currently do not use Droidcam anymore (since the last failed reinstall to be exact), altough I do love the app. It is just such a hassle to reinstall and I would be incredibly thankful if this would be fixed by releasing Droidcam on Flathub!

I'd love to see a Flatpak package for this app. I'm running Fedora Silverblue on my PC, and Flatpak is essentially the native package manager.

Flatpak for the win! o/

+1 here, a flatpak or even an AppImage can be really helpful, can make this work properly on Fedora silverblue...

Please stop spamming here with Flatpak requests. Repeating what has already been said will serve little to achieve your goals. Mostly, you will just annoy people subscribed. Seriously, GitHub has :+1: reaction button for that, do not be annoying.

---

The app requires a kernel module, which cannot be packaged as Flatpak or AppImage. Until the module is merged into the Linux kernel, enabled by default and (ideally) there is portal API for it, having an app on Flathub would likely just result in more support requests.