05 Jan 2026
Planet Debian
Isoken Ibizugbe: Thinking About My Audience
Thinking about who I am addressing is a challenge, but it is an important one. As I write, I realize I'm speaking to three distinct groups: my friends and family who are new to the world of tech, newcomers eager to join programs like Outreachy, and the technical experts who maintain and sustain the projects I work on.
What is FOSS anyway?
To my friends and family: Free and Open Source Software (FOSS) refers to software that anyone can freely use, modify, and share. Think of it as a community garden, instead of one company owning the "food," people from all over the world contribute, improve, and maintain it so everyone can benefit from it for free.
To the Aspiring Contributors
Contributing to an open source project isn't just about writing code. It could involve going over a ton of documentation and understanding a specific coding style. You have to set up your environment and learn to treat documentation as a "source of truth," even if it's something you help modify and improve later.
Where I come from, this world is fairly unknown, and it seemed quite scary at first. However, I've learned that asking questions and communicating are your best tools. Don't be afraid to do your part by investigating and reading, but remember that the community is there to help you grow.
Why Quality Matters
For the past few weeks, I've seen the importance of checking software quality before a release.
Imagine you download a new desktop environment, try to open the calculator or the clock, and it crashes or refuses to start. How annoying is that? Or worse, you download software and can't even install it successfully. My work on creating tests for Debian using openQA is aimed at preventing these experiences. We simulate real user actions to make sure that when someone clicks "Open," the application actually works.
Closing Thoughts
In general, FOSS has empowered people to access and build technology freely. Whether you are here to use the software or you have the expertise to modify and explore it, there is a place for you in this community.
I'm writing this for you, whichever audience you belong to, to show that complex systems become less intimidating when you begin by asking questions.
05 Jan 2026 10:46pm GMT
Hellen Chemtai: Starting out on Open source: Try the OpenQA Debian Image Testing Project
Hello world
. I am an intern at Outreachy and contributing to the Debian Images Testing project since October 2025. This project is Open Source and everyone can contribute to it in any way. The project uses Open QA to automatically install Operating System Images and test them . We have a community here of contributors that is always ready to help out. The mentors and project maintainers are very open to contributions. They listen to any innovative ideas and point out what they have been doing so far.
So far contributions have been in terms of:
- Documentation - Adding to install guides
- Pseudo Tests - Suggesting an idea after finding an error or idea
- Pointing out bugs / errors when trying out tests
- Work on tests
- Contribute towards the wider community / help out other contributors
- Heck, you can even create a screen-cast video doing the set up and add it to the guide / docs
- Developers with further understanding can try to work with the maintainers on packages
Contributing to this project requires some knowledge of Linux commands and Operating Systems. What we will learn later as we go on will be :
- Images / Operating System Installation through dual booting
- More Linux commands
- Images / Operating System Installation and testing on Virtual Machine
- Git commands
- Writing testing documentation
- Writing Pseudo Tests
- Writing test modules / code using Perl
- Working on configuration
Preparation
Before any contribution begins, we would want to first try out the project and run a couple of tests. Get to understand what we are doing first. Let's say you are starting out as a Windows or MacOS user and you want to start contributing. I would recommend dual partitioning your device first. Do enough research and prepare the resources. The network install image just needs at-least 4 GB USB flash drive for dual booting. You will use Debian as the second operating system. Give enough space to Debian, I recommend around 150 GB or more. Also assign at-least 1 GB space to the /boot/efi directory to prevent the low space warnings after a while.This will be a way good way to learn about image installation which is part of the work . I do not recommend Virtual Box because it will hinder full use of system resources. This process will take a day or two.
Set Up and Testing
After dual booting. We log into our Debian System . The next step of instructions will take you through how we set up and run our tests. These instructions have many Linux commands. You will be learning if you are a newbie as you go through the steps. Try to understand these commands and do not blindly copy and paste. You can start your contributions here if you have a suggestion to add to the install docs. Run some tests then log in the Web UI as per the instructions to view your tests progress. Green means they've passed. Blue means its still running. Red means failed.
Trying Out Ideas
Kudos if you have reached this point. The community of contributors will help if you are stuck. We get to try out our own variations of tests using variables. We will also rely on documentation to understand the configurations / test commands like these
openqa-cli api -X POST isos ISO=debian-13.1.0-amd64-netinst.iso DISTRI=debian VERSION=stable FLAVOR=netinst-iso ARCH=x86_64 BUILD=1310 #This is the test you will run on the guide
openqa-cli api -X POST isos ISO=debian-13.1.0-amd64-netinst.iso DISTRI=debian VERSION=stable FLAVOR=netinst-iso ARCH=x86_64 BUILD=1310 TEST=cinnamon #I have added a TEST variable that runs only cinnamon test suite
You can check specific test suites from the WebUI :

We get some failures at times. Here are some failed tests from a build I was working on.

Here we find the cinnamon test failed at locale module. Click on any module above and it will lead us to needles and point to the where the test failed. You can check the error or try to add a needle if its needle failure.
Try editing a test module and test your changes. Try out some ideas. Read the documentation folder and write some pseudo code. Interact with the community. Try working on some tasks from the community . Create your tests and add them to the configuration. There is a lot of stuff that can you can work on in this community.
It may seem hard to grasp at first as a newbie to Open Source. The community will help you through out even if the problem seems small. We are very friendly and the code maintainers have extensive knowledge. Get to sit with us during one of our meetings and you will learn so much about the project. Learning , networking and communicating is part of contributing to the broader community.
05 Jan 2026 6:41pm GMT
Colin Watson: Free software activity in December 2025

About 95% of my Debian contributions this month were sponsored by Freexian.
You can also support my work directly via Liberapay or GitHub Sponsors.
Python packaging
I upgraded these packages to new upstream versions:
- aiosmtplib
- astroid (fixing a build failure with Python 3.14, as I wrote about recently in Preparing a transition in Debusine)
- billiard (fixing a syntax warning with Python 3.14)
- celery (contributed follow-up fix upstream)
- cloudpickle (fixing a build failure with Python 3.14)
- csvkit
- deepdiff (fixing a build failure with Python 3.14)
- django-auditlog
- django-phonenumber-field
- flake8-builtins
- flufl.lock
- kombu
- peewee
- psycopg2
- pydantic-extra-types
- pygments (prepared transition in Debusine with diff-cover, pydata-sphinx-theme, pymdown-extensions, python-readme-renderer, and python-stack-data; contributed python-stack-data fix upstream)
- pylint (fixing a build failure with Python 3.14)
- pymdown-extensions
- python-aiojobs (fixing a build failure)
- python-aiostream
- python-asttokens (fixing a build failure with astroid 4)
- python-auditwheel
- python-blockbuster
- python-boolean.py
- python-confluent-kafka
- python-django-crispy-forms
- python-django-pgbulk
- python-django-pgtransaction
- python-django-pgtrigger (fixing a build failure with mkdocstrings-python-handlers >= 2)
- python-evalidate
- python-exchangelib (fixing a build failure with Python 3.14)
- python-holidays
- python-lsp-server
- python-lz4
- python-mashumaro (fixing many build failures in other packages with Python 3.14)
- python-moto
- python-persistent
- python-pytest-run-parallel
- python-roman
- python-rx (fixing a build failure with Python 3.14)
- python-telethon
- python-uvicorn (fixing a test failure with current uvloop)
- python-wheezy.template
- python-wslink
- rpds-py
- sphinx-autoapi
- sqlparse
- zope.testing (fixing a build failure with Python 3.14)
Python 3.14 is now a supported version in unstable, and we're working to get that into testing. As usual this is a pretty arduous effort because it requires going round and fixing lots of odds and ends across the whole ecosystem. We can deal with a fair number of problems by keeping up with upstream (see above), but there tends to be a long tail of packages whose upstreams are less active and where we need to chase them, or where problems only show up in Debian for one reason or another. I spent a lot of time working on this:
- actdiag's autopkgtests failed when there are multiple supported Python versions
- khard: FTBFS: dh_auto_test: error: pybuild -test -i python{version} -p "3.14 3.13" returned exit code 13 (contributed upstream)
- pydantic-settings: FTBFS: example.py: error: unrecognized arguments: -bad-arg (forwarded upstream and cherry-picked their fix)
- pydantic: FTBFS: dh_auto_test: error: pybuild -test -test-pytest -i python{version} -p "3.14 3.13" returned exit code 13
- pygame: FTBFS with Python 3.14: sys.getrefcount() AssertionError
- python-auditwheel: FTBFS: dh_auto_test: error: pybuild -test -test-pytest -i python{version} -p "3.14 3.13" returned exit code 13 (contributed upstream)
- python-charset-normalizer could silently build without support for some supported Python versions
- python-confluent-kafka: FTBFS with Python 3.14: Segmentation fault in test_create_topics_api (forwarded upstream and fixed after a debugging hint from them)
- python-django: FTBFS with Python 3.14 (also fixing many build failures in other packages)
- python-memray: FTBFS with Python 3.14: Segmentation fault (some initial debugging; upstream has since got a lot further)
- python-telethon: FTBFS: dh_auto_test: error: pybuild -test -test-pytest -i python{version} -p "3.14 3.13" returned exit code 13 (contributed upstream)
- python-typing-extensions: FTBFS: dh_auto_test: error: pybuild -test -i python{version} -p "3.14 3.13" returned exit code 13
- python-wheezy.template: FTBFS with Python 3.14 (contributed upstream, although they opted for doing it a bit differently)
- storm (made an upstream release with Python 3.14 support)
- twisted: Autopkgtests fail with Python 3.14: builtins.RuntimeError: There is no current event loop in thread 'MainThread' (forwarded upstream and cherry-picked their fix)
- zope.proxy and zope.security had a bootstrapping loop when adding new supported Python versions; I broke this loop so it shouldn't bother us again in the future.
Fixes for pytest 9:
- celery (contributed upstream)
- pytest-pylint (contributed upstream)
- python-expandvars (contributed upstream)
- python-inline-snapshot
I filed lintian: Report Python egg-info files/directories to help us track the migration to pybuild-plugin-pyproject.
I did some work on dh-python: Normalize names in pydist lookups and pyproject plugin: Support headers (the latter of which allowed converting python-persistent and zope.proxy to pybuild-plugin-pyproject, although it needed a follow-up fix).
I fixed or helped to fix several other build/test failures:
- dpath-python
- flask-bcrypt: FTBFS: E ValueError: password cannot be longer than 72 bytes, truncate manually if necessary (e.g. my_password[:72])
- python-aiosmtpd
- python-aiostream
- python-auditwheel on i386 (contributed upstream)
- python-auditwheel on riscv64 (contributed upstream)
- python-bcrypt: Accept pyo3 0.27
- python-django-crum
- python-django-guid
- python-inline-snapshot
- python-laspy
- python-mnemonic
- python-ncls on 32-bit architectures (contributed upstream)
- python-papermill
- python-phonenumbers
- python-pluggy
- python-pycddl: Accept pyo3 0.27
- python-sphinx-autodoc2 (contributed upstream)
- python-structlog
- python-wikkid: FTBFS: AttributeError: 'TestBaseParent' object has no attribute 'assertEquals' (contributed follow-up fix upstream)
- python-wslink
Other bugs:
- python-bcrypt: ValueError: password cannot be longer than 72 bytes, truncate manually if necessary
- python-notify2: Directly Build-Depends on dbus
- python-packaging: Mark python3-packaging Multi-Arch: foreign
- python-pyproject-parser: python3-pyproject-parser needs a dependency on python3-consolekit
- sphinx: Please backport upstream's fix on roman-numerals
Other bits and pieces
- db1-compat: Please remove/replace usage of dh_movetousr
- debmirror: Refresh mirror_size documentation
- groff: FTBFS randomly
- openssh: Misleading verbose output for local-to-local or standard remote-to-remote copies (upstreamed an improved version of a patch we've been carrying since 2008)
- pcmciautils: Please remove/replace usage of dh_movetousr
Code reviews
- openssh: Fix binary name in ssh-askpass-gnome.desktop (still in discussion)
- python-lsp-server: Increase tests timeout further
- rope: New upstream version 1.14.0 (merged and uploaded)
- trn4: Update/add Catalan po-debconf translation (merged)
05 Jan 2026 1:08pm GMT