Arch Linux User Repository

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 :)

Is it possible to rename the launcher/icons to "franz" instead of "franz-bin"? This is breaking themes.

@lukeab: it should be fixed by now :) @gdonval.. honestly this is getting annoying. Did you even read the stuff on your own link? As I said before all license file of every single framework being used is included. Also as in your own source stated: "I had the task of going through this a few weeks ago in order to provide our legal team with the technical details on how Electron supports proprietary codecs.[...] A bit more digging and I couldn't find any GPL licensed code in a built checkout of libchromiumcontent. I then clocked that libx264 is for Encoding, not decoding - hence the separate nature of the --enable-libx264 flag." "3. GPL licensed code in FFmpeg FFmpeg can be configured to use GPL licensed code, but it is not configured that way in Chromium." So I would recommend to leave this to the devs. I would say I did my work by asking them myself as well as verifying the different licenses. If you want to know more then please use my contact here or ask them yourself directly so it won't spam things here. Oh and I do agree with you that it would be indeed nicer to use system libraries yes, but since both ways are okay I will leave it as it is for now and when I got time I will have a look into this. But you are also always welcome to create a pull request in my repository where I host this package then I will merge it. But as I said for now I consider it a may-have and not a must-have.

And another thing his lawyer may think about twice: https://github.com/electron/libchromiumcontent/issues/178 and it so happens that the provided version of FFmpeg seems to be compiled with libx264 making Franz GPL.

@Hering: then do as you please. Just make sure his lawyer really does understand what a "copyright notice" is and also make sure that he actually read the MIT license text at least once, which I copied here just in case: """ Copyright (C) [year] [copyright holders] Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. """ Because as it is now, your package does not comply (I repeat, you copied the wrong LICENSE file in your PKGBUILD) and as far as I can tell neither does the original developer.

@lukeab: Yes, sorry this wasn't supposed to be. It will be fixed shortly. @gdonval: Androm didnt take over, I asked him to help me bring the updates as quickly as possible. Now to your "problems": 1. All relevant license files ARE provided. According to the AUR standards I install the license file to /usr/share/licenses/franz-bin NOT replacing the one provided by the developers. This is done to give the developers a chance to place their own one there. BUT as I said all relevant license files are included. The things with ffmpeg etc which you stated before do not apply here because the developers use the electron framework which is released under the MIT license and they work closely with nodejs together. Also they do include these libraries so franz did everything right by releasing their software under MIT as well and they do provide the licenses of electron and all the others needed. This was discussed with the developers as well. 2. Yes it is allowed but since I filed the deletion request of the other package after I created this new one I did so to allow both to be installed. 3. Most software in my /opt/ path does this including most major development platforms. Also as stated in (1) it is not franz including these libs themselves but the used framework (electron). So in short this package is legal and everything was controlled by a lawyer from the franz developers so you do not have to worry about. And by the way your deletion request last time didn't succeed either but it was deleted after I requested one for being a duplicate of this new one.

Hiya, the desktop file has the line Exec=Exec=franz -- %u but you've packaged /usr/bin/franz-bin not /usr/bin/franz small fix.

Hi Androm. First of all, thanks for taking over. This is very much appreciated. I mean it. There are still one outstanding problem and a few minor ones though. Starting with the minor ones that anyone interested can help with: 1. You are not copying the correct license file in your PKGBUILD: you are using the (empty) license file from the package instead of the (incomplete but non-empty) license file provided *with* the PKGBUILD. 2. Even if the package is called 'franz-bin', you are allowed to `provides=` 'franz' as a program name instead of 'franz-bin'. 3. You may also want to `replaces=` the previous 'franz' package in order to have people migrate to this new package (since the other one was deleted). 4. Providing a package as an isolated folder in /opt is frowned upon: `franz` should be provided in /usr/bin, the .so files (i.e. shared libraries) should be removed to use the native Archlinux packages, all the binary blobs should be provided in /usr/share/franz-bin or equivalent. Note: replacing the shared libraries shouldn't be a problem at all, however having franz looking at another place for its binary stuff requires upstream action. I suggest franz should look at different standard-ish places and/or use an environment variable to solve the problem everywhere. With upstream support, these minor enhancements are only a matter of copying the correct files in the correct places and removing everything that is not needed. :) Then comes the outstanding problem: missing license files. I wish that problem was solved *before* creating this new package (though I won't ask for deletion just yet). I just want to explain why providing illegal packages is a real problem. No, as a maintainer there is virtually no chance that you are put into jail or requested money because you provided an illegal package. The problem is the quantity of infringing packages: one illegal package in 10000 will be considered a genuine mistake and the only real action that will be taken is removing the offending package. However, if most of the packages from the same maintainer are found to be illegal, that maintainer may also be banned. And if "many" packages on AUR were found to be illegal (even because of a missing file), AUR itself could be taken down. Note that "many" could mean "a very few" depending on what the other infringements are and who is attacking. This is why the AUR guidelines are really picky about those stuff: https://wiki.archlinux.org/index.php/Arch_packaging_standards#Licenses