This is an idea list, not a work plan. The inclusion of an idea does not guarantee that it will be picked up by a developer.
DKMS is not eweOS-compatible, and a new, eweOS-compatible mechanism needs to be written in order to manage kernel modules.
More Info
- Design a manager to build, install and remove kernel modules automatically
- Integrate it with pacman to trigger actions on package operations (kernel upgrades, module package installs/removals).
- Write testing and documentation
- A fully functional EKMS system that allows eweOS users to easily build, install, and manage kernel modules
Systemd integrates systemd-logind to track user sessions and seats, providing both D-Bus API and C API (through libsystemd) for querying these information. Many desktop applications, such as polkit and wireplumber, depend on the API. elogind implements these APIs but it's split from systemd source and thus unreliable and dirty. Without systemd, eweOS integrates turnstile to manage user session and per-session service managers. But it doesn't come with APIs to query these information.
This aims to communicate with the upstream of turnstile (Chimera Linux) and implement a necessary set of APIs to get turnstile supporting most Linux desktop applications. To keep compatible with programs relying on libsystemd/elogind-style API, a wrapper library may be required as well.
More Info
- Create related issue in turnstile upstream with the situation explained
- Discuss with turnstile developers, determining the necessary set of APIs
- Help with the implementation if possible
- Write libraries/daemons to wrap turnstile API into libsystemd-style ones
- Enabling session-related features in eweOS packages as a real-world test against the implementation
- Well-documented APIs are implemented in turnstile, suitable for usage of real-world Linux programs
- A library serves as compatible layer between sd-login and turnstile APIs
- Disabled features on eweOS due to missing session tracking API get enabled.
¶ GRand Unified Boot Config Generator
GRUB was the old bootloader used by eweOS and Limine has replaced its place. U-boot is another bootloader popular among devboards and we want to support it as well. This aims to implement a generic framework, which evaluates some scripts to check available boot entries and create configuration for them, like grub-mkconfig. The difference is that GRUBCG is designed to support multiple different bootloaders.
More Info
- Design API to describe boot entires between the framework, the generator backend and scripts for deciding boot entries.
- Implement backends for U-boot (extlinux.conf) and Limine
- Packaging on eweOS, add appropriate triggers to regenerate boot configuration automatically on system upgrades
- Well-documented configuration generator with Limine/U-boot support and eweOS integration
Evaluate uutils-coreutils as a potential replacement for parts of Busybox to modernize the userland.
More Info
- Package
uutils-coreutils for eweOS.
- Identify which Busybox applets can be replaced by uutils counterparts.
- Test compatibility with critical system scripts (e.g., makepkg, init scripts, pacman hooks) which often rely on specific flags.
- Create a metapackage or split package scheme to allow users to switch between Busybox and uutils.
- A working eweOS system where the majority of core utilities are provided by uutils.
- A report detailing missing features or incompatibilities found during testing.
¶ Package openjdk (latest version) on riscv64 and loongarch64
Since there is no pre-compiled version of openjdk for musl for the riscv64/loongarch64 architecture, eweOS has not yet packaged the latest version of openjdk on riscv64/loongarch64. Packaging it will predictably require some patches and modifications.
More Info
- Upgrade the openjdk in eweOS to the latest version (24).
- Build the latest version of the openjdk for the riscv64/loongarch64 architecture in eweOS.
- (Optional) Upstream related patches if possible.
- A working openjdk (latest version) on riscv64 for eweOS
Currently, Open Build Service is used by eweOS as building system. We found its pacman support, especially the PKGBUILD parser implemented in Perl with mostly regex, is quite flaky and lacks of bash features. This aims to improve the PKGBUILD parser to provide better compatibility with ArchLinux-like packaging convention.
More Info
- Implement array expansion (
makedepends+=("${_common_deps[@]}"))
- Implement parameter expansion (
source=("xxx/${pkgver//./_}"))
- Correctly parse comments in arrays (see useful links)
- Find a way to parse/evaluate dynamic modification to the properties (
[ "$ARCH" = "x86_64" ] && makedepends+=(nasm))
- Implement first three missing features in OBS and upstream the support
- If possible, figure out a solution for dynamic modified properties. This is likely to be hard thus isn't a hard requirement.
- pacman packaging experience, knowledge about PKGBUILD format
- Perl programming
Similar to ArchLinux, eweOS also plans to build a User Repository, which we will call EUR. The difference is that instead of using the AURweb scheme, we want to write our own distributed repo management system, where the code will be hosted in the user's own git repo. This means that we'll also need a corresponding EUR Helper.
More Info
- Write a workflow for parsing the contents of .SRCINFO and structuring it (e.g. json).
- Write a set of workflows that use the above tools to automatically scan distributed git repositories against a list and update structured data.
- Choose one:
- Write a set of AURweb-compatible api's to make EUR compatible with the existing AUR Helper.
- Write a EUR Helper that provide the same basic functionality as the AUR Helper, such as searching, downloading, and building.
- A usable, auto-refreshing repository of EUR metadata from distributed git repositories.
- Any User Repository helper that works.
eweOS is a relatively small distribution and perfect testing usually means a lot of duplicated work, which isn't practical for our developers. Luckily, OpenQA provides a method to convert manual testing steps into scripts and check the result automatically.
This aims to setup an automatic testing infra based on OpenQA and write corresponding testcases for eweOS, enhancing reliability and reducing manual work.
More Info
- Setup an OpenQA x86_64 instance for eweOS
- Write testcases to verify functionalities against tools included in eweOS desktop liveimage.
- Write testcases to perform an installation in eweOS desktop liveimage.
- Write testcases to check the installation works as expected.
- A suite of testcases to verify functionality of eweOS desktop liveimage.
Currently, os-repo-auto.ewe.moe uses a static redirection logic. We need a more robust service to handle geographical redirection accurately to ensure users download packages from the nearest/fastest mirror.
More Info
- Develop a redirect service for repositories
- Develop a mechanism that can redirect mirrors based on the user's location
- Implement a health-check mechanism to avoid redirecting users to down/out-of-sync mirrors
- Create an API to list active mirrors for pacman mirrorlist generation.
A deployed service that reduces download latency for global users and provides automatic failover
¶ Creating, editing and organizing of wiki content
Currently the eweOS Wiki is still not organised in a neat way and lacks a lot of guidance for users and developers. The lack of guidance on some key steps has led to users having to seek help from community developers to install or configure eweOS, and the lack of documentation has left contributors with no way to get started with eweOS packages, infrastructure, and workflows.
More Info
- Write guides about eweOS installation on the Wiki
- Write guides about eweOS configuration for a graphical desktop and/or command line environment
- Improve the table of contents and chapter structure of the Wiki.
- Write packaging guidelines for developers on different package topics (e.g. programming languages like Python, Perl, Go, or build tools like CMake or meson).
- Improvements and contributions to the Wiki as described above
- Markdown
- Basics about the system maintenance of Linux distros
- PKGBUILD-based packaging (required to write the wiki for developers)
- One or more programming languages (required to write the wiki for corresponding topics)