Recipe for packaging Electron apps
an idea by bear454
Updated almost 4 years ago. 1 hackers ♥️. Has no hacker: grab it!

Electron apps are popping up everywhere, from the Atom editor to the Rocket.Chat client to Kap, a cross-platform open-source screen recorder. Electron apps are based on web technologies, and built from the ground up to be platform-agnostic.

The electron framework is open source, and most of the apps are as well, but they are typically distributed (for Linux) as either a tarball or via npm.

At the very least, I'd like to develop a straightforward recipe for packaging an electron app as an RPM from a vendor tarball; at best I'd like to see how far we can go towards automating the process in OBS (for example, adding some electron-macros, and using linked sources).

No Hackers yet

Join this project

Looking for hackers with the skills:

packaging obs

This project is part of:

Hack Week 15

Activity

  • almost 9 years ago: hennevogel liked this project.
  • almost 9 years ago: bear454 added keyword "packaging" to this project.
  • almost 9 years ago: bear454 added keyword "obs" to this project.
  • almost 9 years ago: bear454 originated this project.


    • Comments

    • MargueriteSu
      almost 9 years ago by MargueriteSu | Reply

      Hi,

      I am one of the maintainers for devel:languages:nodejs in openSUSE.

      Since you're planning to invent a way to package electron apps in openSUSE. I think you would like to know the current status of electron itself on OBS:

      There's currently no native build of electron in any distro. I am the first person trying to do this.

      I have finished "libchromiumcontent" package, which is solid and specfile taken away by many other distros.

      But I didn't finish electron yet. Its build script written in Python and focus on building electron on your own machine instead of a standard virtual build machine (it uses 'git' at build time). So we need to patch it and split dependencies.

      It looks easy but I have another much more important project to develop, that is the packaging tool for nodejs modules in openSUSE. It is the fundamental thing of nodejs packaging in openSUSE. see: https://hackweek.suse.com/15/projects/1880

      Any help appreciated on building electron natively.

      BTW: you can use the prebuild electron to avoid this kind of trouble if you have no interest in packaging electron itself.

    Similar Projects

    openSUSE on ZoL from OpenZFS project by jkohoutek

    Idea is to have SUSE system with OpenZFS as root FS.

    Why ZFS

    Ways in which ZFS is better than BTRFS

    Main goal

    Have OpenZFS as install option in the installer and utilize zedenv Boot Environment Manager for SUSE updates install

    Goals

    • synergy of ZFS with dracut, so snapshots are correctly added to the grub
    • synergy of zedenv with zypper
      • before every update snapshot is created
      • when new kernel or other package which requires reboot is about to be installed, the update will be processed to the new boot environment snapshot and grub configuration changed to boot to this new one
    • integrate Root on ZFS as install option to the YaST
    • configure Kiwi for the ZFS install images

    Completed goals

    • prepare ZFS pool compatible with openSUSE installation ✓
    • install openSUSE with root on ZFS ✓
    • boot to the prepared and installed system ✓

    Current progress

    Resources:

    GHC-9.14 and split Hadrian from GHC build by osukup

    Description

    Prepare openSUSE Tumbleweed project for new GHC Haskell compiler and separate builder (Hadrian) from GHC build

    Goals

    • have GHC-9.14 project with working compiler and if possible filled with packageset
    • have Hadrian in own package built with bootstrap compiler to separate Hadrian bootstrap from ghc bootstrap

    Resources

    devel:languages:haskell

    d:l:h:ghc-9.12.x

    opensuse Haskell rpm macros

    opensuse haskell package gen project

    Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

    Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

    Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

    For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

    No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

    The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.

    To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

    • If you don't have knowledge about some of the steps: ask the team
    • If you still don't know what to do: switch to another distribution and keep testing.

    This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

    Pending

    Debian 13

    The new version of the beloved Debian GNU/Linux OS

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    • [ ] Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    • [ ] Package management (install, remove, update...)
    • [ ] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). Probably not for Debian as IIRC we don't support patches yet.
    • [ ] Applying any basic salt state (including a formula)
    • [ ] Salt remote commands
    • [ ] Bonus point: Java part for product identification, and monitoring enablement
    • [ ] Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    • [ ] Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    • [ ] Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    Switch software-o-o to parse repomd data by hennevogel

    Run non-stop in escape road, avoid dangerous traps and test your speed to win spectacularly.

    Improvements to osc (especially with regards to the Git workflow) by mcepl

    Description

    There is plenty of hacking on osc, where we could spent some fun time. I would like to see a solution for https://github.com/openSUSE/osc/issues/2006 (which is sufficiently non-serious, that it could be part of HackWeek project).

    Create a page with all devel:languages:perl packages and their versions by tinita

    Description

    Perl projects now live in git: https://src.opensuse.org/perl

    It would be useful to have an easy way to check which version of which perl module is in devel:languages:perl. Also we have meta overrides and patches for various modules, and it would be good to have them at a central place, so it is easier to lookup, and we can share with other vendors.

    I did some initial data dump here a while ago: https://github.com/perlpunk/cpan-meta

    But I never had the time to automate this.

    I can also use the data to check if there are necessary updates (currently it uses data from download.opensuse.org, so there is some delay and it depends on building).

    Goals

    • Have a script that updates a central repository (e.g. https://src.opensuse.org/perl/_metadata) with metadata by looking at https://src.opensuse.org/perl/_ObsPrj (check if there are any changes from the last run)
    • Create a HTML page with the list of packages (use Javascript and some table library to make it easily searchable)

    Resources

    Results

    Day 1

    Day 2

    • HTML Page has now links to src.opensuse.org and the date of the last update, plus a short info at the top
    • Code is now 100% covered by tests: https://app.codecov.io/gh/perlpunk/opensuse-devel-languages-perl-meta
    • I used the modern perl class feature, which makes perl classes even nicer and shorter. See example
    • Tests
      • I tried out the mocking feature of the modern Test2::V0 library which provides call tracking. See example
      • I tried out comparing data structures with the new Test2::V0 library. It let's you compare parts of the structure with the like function, which only compares the date that is mentioned in the expected data. example

    Day 3

    • Added various things to the table
      • Dependencies column
      • Show popup with info for cpanspec, patches and dependencies
      • Added last date / commit to the data export.

    Plan: With the added date / commit we can now daily check _ObsPrj for changes and only fetch the data for changed packages.

    Day 4

    I started to implement the update functionality. Now it would be nice to do that in a daily workflow.

    Try out Neovim Plugins supporting AI Providers by enavarro_suse

    Description

    Experiment with several Neovim plugins that integrate AI model providers such as Gemini and Ollama.

    Goals

    Evaluate how these plugins enhance the development workflow, how they differ in capabilities, and how smoothly they integrate into Neovim for day-to-day coding tasks.

    Resources