Project Description
Currently, the systemd script that manages OBS workers (obsworker.service) calls a script (obsworker) that launches workers in windows of a screen
session.
Goal for this Hackweek
Migrate the OBS workers scripts from using the screen
window manager to use systemd Service Templates instead.
Resources
- https://www.freedesktop.org/software/systemd/man/systemd.service.html
- https://github.com/openSUSE/open-build-service/blob/master/dist/systemd/obsworker.service
- https://github.com/openSUSE/open-build-service/blob/master/dist/obsworker
- https://linux.die.net/man/1/screen
This project is part of:
Hack Week 21 Hack Week 22
Activity
Comments
-
almost 2 years ago by enavarro_suse | Reply
- https://github.com/openSUSE/open-build-service/pull/13793
Similar Projects
Automation of ABI compatibility checks by ateixeira
Description
ABI compatibility checks could be further automated by using the OBS API to download built RPMs and using existing tools to analyze ABI compatibility between the libraries contained in those packages. This project aims to explore these possibilities and figure out a way to make ABI checks as painless and fast as possible for package maintainers.
Resources
https://github.com/openSUSE/abi-compliance-checker
https://github.com/lvc/abi-compliance-checker
https://sourceware.org/libabigail/
Explore the integration between OBS and GitHub by pdostal
Project Description
The goals:
1) When GitHub pull request is created or modified the OBS project will be forked and the build results reported back to GitHub. 2) When new version of the GitHub project will be published the OBS will redownload the source and rebuild the project.
Goal for this Hackweek
Do as much as possible, blog about it and maybe use it another existing project.
Resources
- The Blog post
- Issue: poo#123858 - build.opensuse.org: /usr/lib/obs/service//go_modules.service No such file or directory
Implement a full OBS api client in Rust by nbelouin
Description
I recently started to work on tooling for OBS using rust, to do so I started a Rust create to interact with OBS API, I only implemented a few routes/resources for what I needed. What about making it a full fledged OBS client library.
Goals
- Implement more routes/resources
- Implement a test suite against the actual OBS implementation
- Bonus: Create an osc like cli in Rust using the library
Resources
- https://github.com/suse-edge/obs-tools/tree/main/obs-client
- https://api.opensuse.org/apidocs/
Learn obs/ibs sync tool by xlai
Description
Once images/repo are built from IBS/OBS, there is a tool to sync the image from IBS/OBS to openqa asset directory and trigger openqa jobs accordingly.
Goals
Check how the tool is implemented, and be capable to add/modify our needed images/repo in future by ourselves.
Resources
- https://github.com/os-autoinst/openqa-trigger-from-obs
- https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin/-/tree/master?ref_type=heads
Switch software-o-o to parse repomd data by hennevogel
Currently software.opensuse.org search is using the OBS binary search for everything, even for packages inside the openSUSE distributions. Let's switch this to use repomd data from download.opensuse.org
Explore simple and distro indipendent declarative Linux starting on Tumbleweed or Arch Linux by janvhs
Description
Inspired by mkosi the idea is to experiment with a declarative approach of defining Linux systems. A lot of tools already make it possible to manage the systems infrastructure by using description files, rather than manual invocation. An example for this are systemd presets for managing enabled services or the /etc/fstab
file for describing how partitions should be mounted.
If we would take inspiration from openSUSE MicroOS and their handling of the /etc/
directory, we could theoretically use systemd-sysupdate
to swap out the /usr/
partition and create an A/B boot scheme, where the /usr/
partition is always freshly built according to a central system description. In the best case it would be possible to still utilise snapshots, but an A/B root scheme would be sufficient for the beginning. This way you could get the benefit of NixOS's declarative system definition, but still use the distros package repositories and don't have to deal with the overhead of Flakes or the Nix language.
Goals
- A simple and understandable system
- Check fitness of
mkosi
or write a simple extensible image builder tool for it - Create a declarative system specification
- Create a system with swappable
/usr/
partition - Create an A/B root scheme
- Swap to the new system without reboot (kexec?)
Resources
- Ideas that have been floating around in my head for a while
- https://0pointer.net/blog/fitting-everything-together.html
- GNOME OS
- MicroOS
- systemd mkosi
- Vanilla OS