Package Details: protonmail-bridge 3.10.0-1

Git Clone URL: https://aur.archlinux.org/protonmail-bridge.git (read-only, click to copy)
Package Base: protonmail-bridge
Description: Integrate ProtonMail paid account with any program that supports IMAP and SMTP (Qt desktop application)
Upstream URL: https://github.com/ProtonMail/proton-bridge
Keywords: bridge email mail protonmail protonmail-bridge
Licenses: GPL-3.0-only
Submitter: aimileus
Maintainer: ali.molaei (PMBridge-Devs, BenTheTechGuy, carsme)
Last Packager: BenTheTechGuy
Votes: 106
Popularity: 2.01
First Submitted: 2018-03-02 16:03 (UTC)
Last Updated: 2024-03-21 17:22 (UTC)

Pinned Comments

carsme commented on 2023-12-08 22:34 (UTC) (edited on 2023-12-08 22:35 (UTC) by carsme)

NOTICE: This pkgbase is now produces two packages:

  • protonmail-bridge-core: Containing the core daemon & CLI program.
  • protonmail-bridge: Containing the Qt desktop application.

The second package depends on the first. If you don't have a need for the desktop application, you can now choose to only install protonmail-bridge-core.

This packaging change should be seamless and no action should be required before or after the upgrade.

Thanks to @ali.molaei and @BenTheTechGuy for the feedback regarding this change!

bthompson commented on 2021-06-17 04:13 (UTC)

Just having pass installed with a key set up wasn't enough for me, I had to follow this: https://pychao.com/2020/06/10/update-on-using-protonmail-bridge-on-headless-wordpress-linux-servers/

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 27 Next › Last »

carsme commented on 2023-12-07 03:49 (UTC)

@BenTHeTechGuy, Yes precisely, the long-term ambition is for the -nogui package to be merged into this one.

Not overly fond of the -nogui name though, how about -core or -daemon?

@aDogCalledSpot, Happy to hear that! :)

BenTheTechGuy commented on 2023-12-06 22:50 (UTC)

Now that I think about it, I don't know if cli is actually the best name, because it also includes a daemon mode. We could simply call it protonmail-bridge-nogui so that users of the existing package of that name would automatically migrate (we would have to submit a package merge request and push this change as soon as it gets accepted).

aDogCalledSpot commented on 2023-12-06 20:50 (UTC)

Just popping in to say that my build issues have been resolved. Thanks :)

carsme commented on 2023-12-06 20:46 (UTC)

@ali.molaei, @BenTheTechGui, Thanks for the quick feedback!

Point taken on the naming, it would be disruptive to stop delivering the GUI in the package named protonmail-bridge.

I like the idea of the virtual package with the option of either GUI or CLI, but I think it would be nice to avoid any mutually exclusive packages. The GUI for Proton Bridge is built on top of the CLI/daemon so we could just have two packages depending on each other, i.e. GUI pkg depending on CLI pkg, where the CLI pkg can be installed without the GUI.

What do you think of keeping the package name protonmail-bridge for the GUI package but adding a dependency to a protonmail-bridge-cli package?

Not sure it was clear from my earlier comment, but both packages would be built from one PKGBUILD, but with two different package functions. I.e. only one PKGBUILD to keep up-to-date and both packages will always be kept in sync.

See the suggested PKGBUILD:

package_protonmail-bridge-cli() {
  pkgdesc="$pkgdesc (CLI only)"
  depends=(
    glib2
    glibc
    libsecret
  )
  ...
}

package_protonmail-bridge() {
  depends=(
    protonmail-bridge-cli

    abseil-cpp
    gcc-libs
    glibc
    ...
  )
  ...
}

BenTheTechGuy commented on 2023-12-06 20:15 (UTC)

Then users of the current package protonmail-bridge would suddenly have no GUI when they upgrade. I think most users of the Proton Bridge use the GUI. What you could do is split it into proton-bridge-qt and proton-bridge-cli, both providing the now virtual package protonmail-bridge, so users upgrading their installs get a choice. proton-bridge-cli could also conflict and provide protonmail-bridge-nogui so that users of that package automatically migrate when the old one is removed.

ali.molaei commented on 2023-12-06 20:11 (UTC)

@carsme I think this package should rrmain as the GUI package because:

First, people are used to this package bing GUI

Second, this will complicate things with -bin package as well (that needs to be renamed to protonmail-btidge-gui-bin

Third, There is a separate package called nogui so this package can stay as GUI, of there are any optimizations to be made that happen there, this will only switch the position of packages from primary(gui)+nogui to primary(nogui)+gui and I (and I think many people) expect a GUI program when installing this package, If anyone doesn't want a gui, they can install the nogui one. They are separate now, so why complicate things by separating them in the other way again?

carsme commented on 2023-12-06 19:57 (UTC)

I'm considering another change to the packaging - To make this a split package:

  • protonmail-bridge: Containing only core daemon & CLI program.
  • protonmail-bridge-gui: Containing the desktop application.

The first package would be very similar to the package https://aur.archlinux.org/packages/protonmail-bridge-nogui and as such remove the need for a separate nogui package.

The second package would depend on the first.

PKGBUILD suggestion is available here: https://github.com/carlsmedstad/protonmail-bridge/tree/split-package

Let me know if there are thoughts or concerns. Thanks!

betashaft commented on 2023-12-05 19:48 (UTC) (edited on 2023-12-05 19:49 (UTC) by betashaft)

@carsme my build issues are resolved now thank you. And to answer the previous question from @ali.molaei, I had tried a clean build and still had the same errors.

BenTheTechGuy commented on 2023-12-05 15:28 (UTC)

I just built from the previous commit in a clean chroot and it went fine, so I think they have some junk in their SRCDIR or something.

carsme commented on 2023-12-05 14:56 (UTC)

Hey everyone, I've pushed a new pkgrel with the refactored PKGBUILD I suggested in my comment below.

@betashaft, @aDocCalledSpot, do you still experience the build issues?

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 27 Next › Last »