Arch Linux User Repository

@lone-cloud Those dependencies are necessary.

Sure, yarn depends on nodejs so it would be pulled in. However, the guidelines clearly say to not rely on transitive dependencies. In addition, as I said before, upstream declares nodejs LTS as a dependency here, which means it may or may not build properly with a different version, or it may stop working unexpectedly. In fact, now that nodejs is v25 (as of Oct 28), which has breaking changes, the build fails when trying to use nodejs instead of nodejs-lts-jod.

electron is required to launch the app. Upstream just upgraded to version 36 so I've pushed an update to depend on electron36.

bash is required to run the launcher script. Though bash is part of the base system on Arch, explicitly declaring it is standard.

hicolor-icon-theme is required when the hicolor hierarchy (/usr/share/icons/hicolor/) is used. This is standard practice and well-documented (1, 2).

If you personally don't want to use the package, that's perfectly fine, you can use a PWA. Many people prefer packages instead.

Also, just a friendly reminder to abide by the Arch Linux code of conduct.

nodejs-lts-jod, electron35 and hicolor-icon-theme are useless deps from what I can see. Bash too probably.Look at your build steps. It just runs yarn which already requires node if you look at its deps.

I think Proton devs are lazy fucks who just copy and pasted their web app into an electron shell with no changes. I don't see what value anyone would get out of this package. Just install the PWA to get an identical app.

@arielzn I don't think they are unnecessary, since the inbox-desktop package.json specifies electron 35, and node ">= 22.14.0 <23.6.0" is specified in the repo's package.json.

Perhaps for the current version of inbox-desktop, it's forwards-compatible, but I don't want to change the package to use latest versions, and then run into incompatibility later because upstream expected their code to be built with the versions they specified.

there seems to be some unnecessary deps forced here.

'nodejs-lts' is not required as make dep, i used current 'nodejs' package and it was built totally fine.

in addition I tested to use latest 'electron' (v38) instead of forcing v35 and no issues neither.

@as7erism thank you, though I think pushing an unnecessary downgrade would be unwanted. I think for this version I'll change the package to build that branch you mentioned. And I will open an issue with them to see if we can make sure the tags stick around.

edit: #464 is the issue upstream

It seems like every proton-inbox-desktop tag was deleted from upstream for some reason. Also, as @rdhaese pointed out, the inbox-desktop package version on main is 1.9.0. Version 1.9.1 exists on a branch that hasn't been updated in a month.

I threw together a patch (sent to your email @AlphaLynx) that instead fetches via a proton-mail tag. I'm not sure if this is a great solution, as the choice of proton-mail as the tag prefix is mostly arbitrary, and we would be downgrading this package to 1.9.0.

@rdhaese

Gives a 404: source=("WebClients-proton-inbox-desktop-$pkgver.tar.gz::https://github.com/ProtonMail/WebClients/archive/refs/tags/proton-inbox-desktop@$pkgver.tar.gz"

Where pkgver is 1.9.1

That is weird, the proton-inbox-desktop@1.9.1 git tag existed when I uploaded the package. I guess upstream deleted it (and therefore the tarball autogenerated by GitHub was also deleted).

I checked the code in the repo https://github.com/ProtonMail/WebClients/tree/main/applications/inbox-desktop package.json version is 1.9.0.

Yes, it says that on main branch but the latest version is 1.9.1 (see this endpoint, and the .deb download button when you browse to https://proton.me/mail/download, and scroll to Linux app).

Has the latest PKGBUILD update even been tested?

Yes, I tested it extensively. With the tag present (not giving a 404), the package builds successfully in a clean chroot, follows all Arch Package Guidelines, and installs properly. I could not have predicted that upstream would delete the tag.

I dunno, this latest edit seems a mess.

The diff itself may look messy, but that’s because I wrote the package from scratch, and then rebased while keeping only my changes. The package is perfectly fine aside from the 404.

I saw in the diff that the previous version of the PKGBUILD referred to a specific commit.

Yeah, I thought building from the git tag via tarball would be more stable, reproducible, and easier to update the package going forward.

I saw that the -bin package is also updated to 1.9.1, so I'm assuming that one is broken too.

The -bin package works perfectly fine (the .deb link does not 404).

Unfortunately, I will be unable to fix the 404 issue for right now. I’m on vacation, away from my Arch PC until Oct 13. In the mean time, I’m happy to add a co-maintainer if someone has a patch for the source, email me.

Gives a 404: source=("WebClients-proton-inbox-desktop-$pkgver.tar.gz::https://github.com/ProtonMail/WebClients/archive/refs/tags/proton-inbox-desktop@$pkgver.tar.gz"

Where pkgver is 1.9.1

Checked the tags in that repo, couldn't really find one directly, asked an AI to look for me. It swears there is an @1.9.0, but I still get a 404 when testing to download manually. I think it's hallucinating.

I checked the code in the repo https://github.com/ProtonMail/WebClients/tree/main/applications/inbox-desktop

package.json version is 1.9.0.

Has the latest PKGBUILD update even been tested? I dunno, this latest edit seems a mess.

I saw in the diff that the previous version of the PKGBUILD referred to a specific commit.

I saw that the -bin package is also updated to 1.9.1, so I'm assuming that one is broken too.