[Enhancement] APT repository for jitsi-meet-electron?

[taivlam]

Would it be possible to offer this Jitsi desktop client via some APT repository (or have preexisting Jitsi repos include jitsi-meet-electron) for easier installation? I encountered some struggles before even discovering the official jitsi-meet-electron desktop client for a Debian machine and didn't want others to also struggle with the same stumbling blocks.

• I am aware that install it via the AppImage or I can manually install the .deb package from this repository's Releases on Debian-based Linux distros using sudo gdebi jitsi-meet-amd64.deb. I avoid the former because I prefer not to use AppImages. However, the latter isn't entirely perfect since the .deb package isn't configured to "auto-update" jitsi-meet-electron via APT. I could keep track of releases on GitHub via RSS and manually uninstall the old version to install the new version, though I don't see this method "scaling" very well if I have 2 or more Debian machines, even for non-work purposes.

• Additionally, I initially struggled figuring out where to start for installing a Jitsi Meet desktop client on Debian-based distros. I essentially stumbled upon the desktop Jitsi Meet client by accident while browsing the AUR and found the jitsi-meet-desktop and jitsi-meet-electron entries. (I use the former but not the latter on Arch Linux-based distros.) Yes, the AUR is community contributed/unofficial, strictly speaking - however, the ease of installing via the AUR contrasts with my experience on Debian.

After encountering very outdated Debian repos mentioned in #331, I arrived to jitsi-meet-electron here on GitHub - mostly due to the Download page on https://jitsi.org/ not mentioning this client, as described in #265.

• While web searching, I nearly installed the server software jitsi-meet - the stable version to be exact - which is not what I really wanted after spending a few minutes considering what the instructions actually achieved.

• Also I am aware Jitsi Meet "just works" (best on) Chromium-based browsers and is intended to be used in the browser. However, the one feature that the desktop client has is the "Always on Top Window" - the little floating window when you navigate away from the main client window, similar to a feature the Skype desktop client also has - which makes the Jitsi Meet desktop client better than Jitsi Meet in the browser.

[saghul]

This project is mostly maintained out of love. It can't get much time allocated to it, so we mostly implement low-maintenance stuff.

I'm not keen on having to maintain a Debian repo for this.

Adding it to the existing one might be doable, if there is a way to automate it with a webhook or something. I'll check, but no promises.

[532910]

I'm not keen on having to maintain a Debian repo for this.

But jitsi already has a debian repo. https://download.jitsi.org Hope it could be added there.

[saghul]

Read the last sentence of my last message.

[532910]

Yep, I read it, my last sentence it related to yours (:

[saghul]

Looks like you didn't. I know we have a Debian repo. I said I'm not keen on maintaining another one or manyally uploading the package there. If there is a way to automate this, fine, if not, it just won't be done.

[taivlam]

This project is mostly maintained out of love. It can't get much time allocated to it, so we mostly implement low-maintenance stuff.

Thank you for clarifying the nature of this project - I appreciate this. It makes more sense why this hasn't been listed on the Downloads page.

I'm not keen on having to maintain a Debian repo for this.

I'll admit I wasn't really clear on the repo specifics (because I know very few low-level details about them), though I was definitely not considering making this a Debian "official" repo.

Adding it to the existing one might be doable, if there is a way to automate it with a webhook or something. I'll check, but no promises.

Hm, this is interesting approach. This reminds me of how I heuristically enable the Tor Project's repository on Debian in order to install tor-browser on Debian to get the Tor Browser, even though this repository is also intended to install the server software tor - though correct me if I have this mental connection wrong.

Thank you for the consideration, despite the difficulty of maintaining a project out of love - I totally understand if this is not within the maintainers' collective capacity.

[Moonbase59]

I’d also love to see this in the Ububtu/Debian official repo, since there is much confusion for Firefox users, and the Electron app could elegantly solve these issues, without requiring the user to install a full Chromium, and still get the system-built-in updates.

[saghul]

What’s the confusion? Jitsi Meet now has first class support for Firefox. Modulo bugs, but that applies to everything really.

[Moonbase59]

Sad to say, but Firefox is still quite unusable:

• with more than two participants, starts stuttering after a few minutes if only one of them uses Firefox, up to a load of 16 on a 4-core machine, and making the whole system crawl to halt,
• problems to select video and audio sources,
• apparently muting all participants when only one uses Firefox sometimes,
• super-high CPU loads and horrible stuttering when short transmission errors occur
• not too good when sharing screens

Yesterday we held a 4½ hour test conference with 4–5 participants, none using Firefox but all Chromium-based browsers (Chromium, Opera) and the Android app and not one glitch!

So yes, Firefox support is getting better but I still think that browser has a WebRTC problem, and we were more than happy to find your Electron-based Jitsi client—if only it would be easier to install for non-techies. Talking mostly about Linux (Mint, in our case) users, don’t know about Windows.

[csett86]

For the Linux Mint users an easy option may be the flathub package of this electron app, as flathub is preinstalled and configured on Linux Mint. Just point your users to "Software" and look for Jitsi: https://flathub.org/apps/details/org.jitsi.jitsi-meet

[saghul]

Sad to say, but Firefox is still quite unusable:

• with more than two participants, starts stuttering after a few minutes if only one of them uses Firefox, up to a load of 16 on a 4-core machine, and making the whole system crawl to halt,
• problems to select video and audio sources,
• apparently muting all participants when only one uses Firefox sometimes,
• super-high CPU loads and horrible stuttering when short transmission errors occur
• not too good when sharing screens

Yesterday we held a 4½ hour test conference with 4–5 participants, none using Firefox but all Chromium-based browsers (Chromium, Opera) and the Android app and not one glitch!

So yes, Firefox support is getting better but I still think that browser has a WebRTC problem, and we were more than happy to find your Electron-based Jitsi client—if only it would be easier to install for non-techies. Talking mostly about Linux (Mint, in our case) users, don’t know about Windows.

Please report issues on the jitsi-meet repo, this is just the Electeon wrapper.

[csett86]

@saghul I would be happy to build a CI that includes the build number in the .deb and pushes the built .deb on release eg via SSH to a package server, I have done at least the SSH push part eg. here: https://github.com/luki-ev/synod-web/blob/synodim/.github/workflows/main.yml#L33-L49 with the ssh private key then in the GH secrets.

Otherwise if you could shed a little light on how https://download.jitsi.org/stable/, https://download.jitsi.org/testing/ and https://download.jitsi.org/unstable/ are currently automated, I am happy to contribute if I can.

[saghul]

Otherwise if you could shed a little light on how https://download.jitsi.org/stable/, https://download.jitsi.org/testing/ and https://download.jitsi.org/unstable/ are currently automated, I am happy to contribute if I can.

We push packages there using Jenkins.

@damencho Do you think we could somehow push Debian packages from here to the stable repo? Maybe GH actions can trigger a hook in Jenkins so it goes and fishes the new deb and adds it?

[csett86]

The deb package of the latest release also always has a stable URL (as seen in the README), if that helps the Jenkins job: https://github.com/jitsi/jitsi-meet-electron/releases/latest/download/jitsi-meet-amd64.deb

[damencho]

In order to push it to download.jitsi.org we need 3 files *{changes,deb,buildinfo}, are these available for download? Yep, we can trigger a job to jenkins to download those files and push it to stable.

[csett86]

I checked and the *.changes and *.buildinfo are unfortunately not available via fpm, which is internally used by electron-builder to create the deb file. I could manually create the .changes file (similar to https://github.com/jitsi/jitsi-meet-debian-meta/blob/master/build-new-package.sh), but the buildinfo unfortunately is not something that can be easily recreated without the real debian build tools (which are not used in electron-builder).

As the .changes-Files all 403 on https://download.jitsi.org/, how important are they?

[saghul]

IIRC not very, they are a requirement to add the package to the repo though.

[Yuri-M-Dias]

Kinda hijacking this issue, but would it be possible to generate a snap build and have it installable via snap? You only need an account, and it can be easily automated, but this would at least solve the auto-update for some users. https://www.electronjs.org/docs/latest/tutorial/snapcraft/

[saghul]

@Yuri-M-Dias Sorry, we are not currently considering adding more builds.