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. 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. @Abdallah since you've suggested to package whatsapp-desktop, you will likely need to experiment that in a copr repository with a nodejs-electron-whatsapp-desktop (or any other name). Hope this helps. -- _______________________________________________ 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
