Package Details: franz 1:5.10.0-1

Git Clone URL: https://aur.archlinux.org/franz.git (read-only, click to copy)
Package Base: franz
Description: Free messaging app for services like WhatsApp, Slack, Messenger and many more.
Upstream URL: https://meetfranz.com
Licenses: Apache
Submitter: 314eter
Maintainer: ItachiSan
Last Packager: ItachiSan
Votes: 146
Popularity: 0.000000
First Submitted: 2017-10-26 11:34 (UTC)
Last Updated: 2023-09-11 20:46 (UTC)

Dependencies (5)

Required by (0)

Sources (3)

Pinned Comments

ItachiSan commented on 2019-10-07 08:26 (UTC) (edited on 2021-09-08 07:58 (UTC) by ItachiSan)

If you have troubles, read this message!

Please go to the relevant section of this comment in order to make both your and my life easier :)

  1. Errors when starting the app like: the chat area is all blue
  2. (Obsolete) I get an error when upgrading packages

Now, to the resolutions!

1. The app opens but I got a blue screen and nothing more / The app refuses to start / ...

The package depends on Node.js native stuff which are compiled at build time, which makes it break on Electron updates.

With a PKGBUILD between 2020-11-15 till 2021-09-08, you should always have gad a correct matching between Electron and Franz versions.

After 2021-09-08, while the Electron packages follows just the official Arch package dependency, as it is based on not-rolling versions (AKA following a specific Electron branch) breakages are unlikely.

If you would like to help me on this, whenever you have problems starting it, do the following:

  1. Open Franz
  2. Franz is broken: maybe for a recent update?
  3. Reinstall Franz from AUR; this will make it rebuild the native blobs
  4. Re-open Franz
  5. Franz should work fine; if so, it was a Node.js/Electron/else update problem

If the above steps help you, report the package as outdated here and write in the comment something like:

Electron update broke Franz

If you have some other issues, you should open the developer tools and give me its output, in addition to what is your environment, so I can figure out if it is a packaging issue (my job to fix) or an upstream/code issue (their job to fix); in the second case, I will open a bug request and mention it in a comment, so that you can track it.

2. (Obsolete) I cannot upgrade Electron

The following resolution is not valid since 2021-09-08, it is kept for historic purposes

This is intended; since the PKGBUILD for Franz 5.5.0-4, the package marks as dependency a version-locked Electron package in order to avoid issues with binary modules over upgrades.

In such scenario, you should, assuming _electron="electron" in the PKGBUILD (meaning the Electron used is bundled in the package electron):

  1. Mark this package as out of date
  2. Do you regular updates with: pacman -Syu --ignore electron

If you want however to upgrade the Electron package, do

  1. Upgrade the electron package with pacman -S --assume-installed electron=FRANZ.REQUIRED.VERSION electron
  2. Rebuild Franz if needed

Hope this was a good explanation, might get updates if I missed something :)

Latest Comments

« First ‹ Previous 1 .. 9 10 11 12 13 14 15 16 17 18 19 Next › Last »

tgalal commented on 2017-12-06 13:51 (UTC) (edited on 2017-12-11 08:45 (UTC) by tgalal)

a few days ago the dependency node-tar was updated to 4.1.0, and it seems to contain some bug preventing Franz unpacking recipe archives, causing "Could not load service recipe" errors: (See https://github.com/meetfranz/franz/issues/171 scroll down for arch-related comments)

Adding this line in prepare step forces tar v4.0.2, and fixes the error:

sed -i 's/"tar": "[0-9.^]*"/"tar": "~4.0.2"/' package.json

scippio commented on 2017-11-30 10:24 (UTC)

I have some error: > @paulcbetts/spellchecker@4.0.6 install /tmp/packerbuild-1000/franz/franz/src/franz-5.0.0-beta.14/build/node_modules/@paulcbetts/spellchecker > node-gyp rebuild Error output: sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) gyp: Call to 'node -e "require('nan')"' returned exit status 0 while in binding.gyp. while trying to load binding.gyp gyp ERR! configure error .... etc. and have "yarn add electron-builder@19.45.5 gulpjs/gulp#4.0" in PKGBUILD ...

alecmev commented on 2017-11-28 09:59 (UTC)

@314eter Discarded my local modifications and rebuilt, it works. Thanks!

314eter commented on 2017-11-28 09:53 (UTC)

I added the fix from @jeremejevs. Does it work now?

alecmev commented on 2017-11-28 08:48 (UTC)

@chris_muc You need to replace `yarn add electron-builder gulpjs/gulp#4.0` with `yarn add electron-builder@19.45.5 gulpjs/gulp#4.0`.

chris_muc commented on 2017-11-28 07:07 (UTC)

it looks like I have the same issue. For this temporary fix "pin `electron-builder` to `19.45.5`" -> how do I do that?

alecmev commented on 2017-11-27 19:00 (UTC)

Didn't want to install Plasma, so decided to find out where the `C.UTF-8` requirement comes from and why. TL;DR: Here's an issue I have filed on `electron-builder`: https://github.com/electron-userland/electron-builder/issues/2340 The temporary fix is to pin `electron-builder` to `19.45.5`. Please, do that. I think if you install the latest `electron-builder` (`19.46.*`) and try building, it'll break for you too (though wouldn't put my money on it, maybe you do have `C.UTF-8` from somewhere somehow, `locale -a` should tell).

<deleted-account> commented on 2017-11-27 16:08 (UTC)

Actually I am not using it myself, only running it to test if it works but yes it does here. I do use Plasma though. Could you try that and see if that makes a difference?Usually locale is provided by glibc.

alecmev commented on 2017-11-27 15:16 (UTC)

Yep. I also just cloned the repo and installed the latest `electron-builder` + `electron-updater`, and ran `yarn build`, and I'm getting the same error, so this isn't an issue with PKGBUILD. This package works for you, I assume? What's the difference between our environments? I'm running a fairly minimal i3 setup, no GNOME or KDE or anything, no special i18n stuff. Could something not in the core install be providing the `C.UTF-8` locale? Could I somehow add it myself?

<deleted-account> commented on 2017-11-27 15:05 (UTC)

Can you run `sudo locale-gen en_US.UTF-8` without problems?