Alper Nebi Yasak

Debian on Chromebooks: The Final Steps?

I have been working on improving Debian’s kernel and installer support for Chromebooks (Google’s very non-standard laptops) during the last years. At DebConf24 I have presented another talk titled Debian on Chromebooks: What’s New and What’s Next? where I gave an overview of what problems remain unsolved. I have managed to fix almost all of those, and with luck the low-level side of it will be finally complete by the time I hold this talk, so I’d like to give another status report on it.

You Too Can Fix That Bug on That Weird Architecture

Just before the Debian Trixie freeze, I worked on upgrading Debian’s PulseAudio package to the upstream version 17.0 for improved hardware support on devices I care about. However, it depended on a new upstream version of the WebRTC Audio Processing library, which hadn’t been updated for years in the Debian archive, and would fail to build on the mips64el architecture. Being somewhat familiar with running foreign-architecture programs through emulation for ARM systems, I decided to try fixing it without knowing anything about MIPS…

That mips64el architecture might be gone from the archive now, but Debian supports a great deal of different CPU architectures. So, this talk is about ways to build, run, test, investigate and fix foreign-architecture programs and packages on your ordinary AMD64 system, from an advanced beginner, with a real-life example. Maybe even mentions of other common problems that might come up, tricks and solutions you can use. But the main point is, architecture-specific bugs are not arcane magic that only wizards can comprehend. Probably.

Debian Installer Workshop

In this workshop I’ll try to do a live demonstration of the process of developing for, testing and debugging the Debian Installer. I would prefer to do that by implementing a feature or fixing a bug as suggested by the audience, so it may end up being a mostly improvised interactive work session.

git-merge-dch: A Git Merge Driver for Debian Changelog Files

One thing that annoys me quite frequently when doing Debian-related development is having to manually resolve conflicts on the debian/changelog file every time the upstream code gets updated. Changelogs appear to have a simple format: a series of entries each with a few independent lines per change. Fixing merge conflicts should be automatic and invisible. I should never get an email from Salsa for a debian/changelog conflict in my merge requests just because the maintainer added a new change or finalized an entry. Maybe except in extreme cases.

One would expect git to handle these conflicts gracefully, but it simply gives up when seeing a context mismatch, which happens almost every time. Even worse, it will happily and silently merge changes into an already released changelog entry. There is dpkg-mergechangelogs, but it’s fundamentally the wrong tool to use because it assumes finalized non-conflicting version numbers and changelog entries, the opposite of what happens in development e.g. when rebasing your changes onto upstream packaging.

Eventually I got annoyed enough to start writing something that can properly merge debian/changelog files. It’s not as simple as it sounds, and my affinity to find edge cases makes it worse. In the talk I’ll try to define the problem domain, highlight some weird cases with life-like examples, and demonstrate spooky action at a distance. I don’t know if the merge driver itself will be finished in time for the talk, in which case this will also serve as a request for help.