




















nodejs 24 has released, and packages nodejs-lts-jod (22) and nodejs-lts-krypton (24) are in conflict. Any chance this can be updated for nodejs-lts-krypton?
@myosot Thanks for the comment, yes this is the right place to discuss issues like that. I'm not seeing that build failure on my machine. Can you try building in a clean chroot (without any changes to the PKGBUILD), if this works then it's likely due to a configuration on your machine.
I've been able to install this by editing the PKGBUILD directly and adding "yarn add node-gyp" after the YARN_CACHE_FOLDER export, otherwise yarn fails at building sharp on my machine. Unsure if this is because of something I messed up on my end or not.
Im new to using arch, im sorry if this is not supposed to be discussed in comments, feel free to remove this if not and im sorry for any inconvenience.
@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.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。
upstream still uses nodejs 22, so I'll continue to use that dependency. It might work fine on nodejs 24, and you're welcome to try that by changing locally.