On Fri, Oct 9, 2026 at 10:43 AM Nicolas Chauvet <[email protected]> wrote: > > Le ven. 9 oct. 2026 à 16:04, Neal Gompa <[email protected]> a écrit : > > > > On Fri, Oct 9, 2026 at 9:59 AM Nicolas Chauvet <[email protected]> wrote: > > > > > > Le ven. 9 oct. 2026 à 14:36, Neal Gompa <[email protected]> a écrit : > > > > > > > > On Fri, Oct 9, 2026 at 8:03 AM Abdallah Shehawey <[email protected]> > > > > wrote: > > > > > > > > > > I am the upstream author of whatsapp-desktop, an independent > > > > > GPL-3.0-or-later desktop client for WhatsApp Web with tray > > > > > integration, notifications, themes, configurable fonts and privacy > > > > > controls. It requires an existing WhatsApp account and Internet access > > > > > and is not affiliated with Meta or WhatsApp. > > > > > > > > > > I have prepared a source-only application packaging proposal. It > > > > > installs JavaScript and data and depends on a separately packaged > > > > > Electron >= 40, < 41; the application build neither downloads Electron > > > > > nor runs npm. The application tests and package builds pass in clean > > > > > Ubuntu 24.04 and Fedora 44 environments. Fedora rpmlint reports zero > > > > > errors and warnings. > > > > > > > > > > Public source review artifacts (Fedora SPEC/SRPM and Debian > > > > > .dsc/orig/quilt sources, with checksums): > > > > > https://github.com/abdallah-shehawey/whatsapp-desktop/releases/tag/packaging-review-2026-10-09 > > > > > > > > > > Merged packaging changes and validation: > > > > > https://github.com/abdallah-shehawey/whatsapp-desktop/pull/6 > > > > > > > > > > Debian ITP, acknowledged by the BTS: > > > > > https://bugs.debian.org/1150415 > > > > > > > > > > The key prerequisite is Electron: it is not currently packaged in the > > > > > target official archives, and Debian's runtime request > > > > > https://bugs.debian.org/842420 remains open. The ITP is explicitly > > > > > blocked on that runtime work. I have not completed Electron source > > > > > packaging, and these application artifacts are not an accepted or > > > > > currently installable official archive package. > > > > > > > > > > > > > Electron is present in Fedora. It is currently in Rawhide (which will > > > > eventually branch to become Fedora 46), but it is present. However, we > > > > will only maintain one version of Electron, Right now, nodejs-electron > > > > is on v43, and it will likely move to v44 soon. > > > > > > > > > I would like to pursue inclusion in Fedora's official repositories. > > > > > Could a Fedora packager advise on the Electron prerequisite, review > > > > > eligibility for this independent web-service client, and sponsorship > > > > > for a new contributor? The directly downloadable SPEC and SRPM are > > > > > linked above. I understand that a formal Fedora Package Review must be > > > > > filed through a Bugzilla account tied to my Fedora Account System > > > > > email; this email is a request for packaging guidance, not a claim > > > > > that a formal review has already been filed. > > > > > > > > > > > > > You'll need to update your software to work with newer versions of > > > > Electron. I don't know much about your application beyond that, since > > > > I haven't looked. Perhaps someone else familiar with Nodejs > > > > applications may be willing to look at this once you've updated your > > > > code. > > > Out of curiosity, which package uses this packaged electron in rawhide ? > > > > > > Having every electron based application to rely on the same pace > > > update of the base electron package looks unreliable. That's because > > > not every package maintainer can rise up at the same time (not even > > > talking about having upstream rebased at the same time, dealing with > > > various difficulties or even real life issues). It's not more reliable > > > to have a slow pace electron package because it's just moving the same > > > problem. > > > > > > I would prefer to amend the alternate version policy (that allows a > > > "per-version" namespace of a given package). > > > That way we can have a "per-consumer" based namespace. So having > > > electron-whatsapp-desktop and others (signal, elementary, etc). > > > > > > That's the only way forward to this long standing issue. > > > > Unless you want to maintain all the different chromium codestreams in > > parallel, that's probably not happening. > That would be a given. The alternative is to bundle the electron into > the "consumer application" which is what is done with the element > > > It was introduced in order to package podman-desktop, which has a > > review request: https://bugzilla.redhat.com/2527713 > > So it means podman-desktop will control the pace of the > nodejs-electron package updates. > This is very much "the problem". Another electron enabled package > could end-up having a different pace. >
Ideally there's a SIG for Electron applications so that it can be coordinated and multiple people can work together instead. This is not a new problem for us in Fedora and it is generally expected that we work with various upstreams to resolve the issue. > In the whatsapp-desktop case , the electron used is >= 40 < 41. So it > will likely never be able to use a system(aka podman paced based) > nodejs-electron package. > The packager is the upstream developer. They can fix it. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
