Maintaining QEMU in SUSE and openSUSE: A Developer’s Guide
As a QEMU developer for SUSE and openSUSE, I would like to share some insights into how we maintain the QEMU package across multiple enterprise and community distributions. If you are interested in contributing, this guide should help you understand the workflow.
1. Why QEMU Maintenance Is Challenging
QEMU is probably the second most complex package in Linux — only behind the kernel.
In SUSE/openSUSE, we maintain three related packages:
- qemu
- qemu-linux-user
- qemu-testsuites
In addition, we support multiple product branches simultaneously:
- SLE11SP4
- SLE12, SLE12SP1–SP4
- SLE15, SLE15SP1–SP3
- openSUSE Leap (15.x series)
- openSUSE Tumbleweed
Every fix or change must be evaluated carefully:
- Which branch requires the fix?
- Is backporting needed?
- Should it apply to all maintained versions?
Missing a branch is easy. Coordinated maintenance is essential.
2. Infrastructure Overview
We use two main systems:
- GitHub (openSUSE) / GitLab (SUSE) – source control
- OBS / IBS – package build system
Git manages source patches. OBS/IBS manages RPM packaging and builds. Both must stay in sync.
3. Types of Maintenance Work
1) Bug Fixes
- Apply patch to Git repository
- Write a clear changelog entry
- Test appropriately
- Submit a Source Request (SR)
Straightforward if the patch is well-scoped.
2) Version Upgrades
Usually handled by senior maintainers.
- Create new branch from upstream release
- Backport downstream patches
- Drop patches already merged upstream
- Resolve conflicts
- Submit SR with clean changelog
Version upgrades require deep understanding of both upstream QEMU and downstream customizations.
3) Packaging-only Changes
If changes only affect:
- Spec files
- ROM handling
- Packaging logic
You can modify directly in OBS/IBS without touching Git source.
4. Example Workflow: Backporting a Fix
Step 1 – Select Target Branch
git checkout SLE12-SP2 -b b-branchname
Step 2 – Apply Patch
Option A: Cherry-pick from upstream
(cherry picked from commit 2bd3f8998e1e7dcd9afc29fab252fb9936f9e956)
[LY: BSC#1121600]
Signed-off-by: Liang Yan <lyan@suse.com>
Option B: Downstream-only patch
We strongly encourage submitting fixes upstream first. Downstream-only patches are carefully reviewed.
Step 3 – Work in OBS
Example project:
https://build.opensuse.org/package/show/Virtualization/qemu
Checkout your working branch:
osc co Virtualization/qemu
This creates a personal branch:
home:username:branches:Virtualization/qemu
Always perform modifications in your branch workspace.
Step 4 – Sync Git Changes into OBS
osc update
bash update_git.sh
Our internal script:
- Pulls latest Git commits
- Generates patch automatically
- Updates spec file
Step 5 – Update Changelog Properly
Since we maintain three packages:
- qemu
- qemu-linux-user
- qemu-testsuites
You must update the correct changelog(s).
- If affecting core QEMU → update qemu.changelog
- If affecting linux-user → update qemu-linux-user.changelog
- If common change → update both appropriately
Use internal helper script when applicable:
bash pre_stack.sh
Be precise. Clear changelogs reduce review cycles.
Step 6 – Submit Source Request
osc sr -m "Detailed description of change"
Expect feedback. Address review comments patiently and thoroughly.
Step 7 – Sync Back to Git
Do not forget to push your branch changes:
git push
Git and OBS must remain consistent.
5. Final Notes
Maintaining QEMU across enterprise and rolling distributions requires:
- Strong understanding of upstream QEMU
- Careful branch coordination
- Disciplined packaging workflow
- Clear documentation and changelog hygiene
It is complex, but also rewarding.
If you are interested in contributing to QEMU maintenance in SUSE/openSUSE, we welcome collaboration.
Build carefully. Review thoroughly. Maintain responsibly.