Here s my monthly but brief update about the activities I ve done in the FOSS world.
Debian
Whilst I didn t get a chance to do much, here are still a few things that I worked on:
Did a few sessions with the new DFSG team to help kickstart things, et al.
Assited a few folks in getting their patches submitted via Salsa.
Mentoring for newcomers.
Moderation of -project mailing list.
Ubuntu
I joined Canonical to work on Ubuntu full-time back in February 2021.
Whilst I can t give a full, detailed list of things I did, here s a quick TL;DR of what I did:
wordpress: There were multiple vulnerabilities reported in Wordpress, leading to Sent Data & Cross-site Scripting.
[bookworm]: Roberto rightly pointed out that the upload to bookworm hadn t gone through last month, so I re-uploaded wordpress/6.1.9+dfsg1-0+deb12u1 to bookworm-security.
ruby-rack: There were multiple vulnerabilities reported in Rack, leading to DoS (memory exhaustion) and proxy bypass.
[ELTS]: Last month I had backported fixes for CVE-2025-46727 & CVE-2025-32441 to buster and stretch but the other backports were being a bit tricky due to really old versions.
I spent a bit more time but there s a lot to demystify. Gonna take a bit of break from this one and come back to this after doing other updates. Might even consider sending a RFH to the list.
libwebsockets: Multiple issues were reported in LWS causing denial of service and stack-based buffer overflow.
Backporting tests was an interesting exercise as I had to make them compatible with the bullseye version. :)
ceph: Affected by CVE-2024-47866, using the argument x-amz-copy-source to put an object and specifying an empty string as its content leads to the RGW daemon crashing, resulting in a DoS attack.
[LTS]: Whilst the patch is straightforward, backports are a bit tricky. I ve prepared the update but would like to reach out to zigo, the maintainer, to make sure nothing regresses.
[ELTS]: Same as LTS, I d like to get a quick review and upload to LTS first before I start staging uploads for ELTS.
[LTS] Attended the monthly LTS meeting on IRC. Summary here.
It was also followed by a 50-minute post-meeting technical discussion/question session.
[E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates. Thanks, Sylvain, for a great documentation summary.
I am a huge fan of Git, as I have witnessed how it has made software development so much more productive compared to the pre-2010s era. I wish all Debian source code were in Git to reap the full benefits.
Git is not perfect, as it requires significant effort to learn properly, and the ecosystem is complex with even more things to learn ranging from cryptographic signatures and commit hooks to Git-assisted code review best practices, forge websites, and CI systems.
Sure, there is still room to optimize its use, but Git certainly has proven itself and is now the industry standard. Thus, some readers might be surprised to learn that Debian development in 2025 is not actually based on Git. In Debian, the version control is done by the Debian archive itself. Each commit is a new upload to the archive, and the commit message is the debian/changelog entry. The commit log is available at snapshots.debian.org.
In practice, most Debian Developers (people who have the credentials to upload to the Debian archive) do use Git and host their packaging source code on salsa.debian.org the GitLab instance of Debian. This is, however, based on each DD s personal preferences. The Debian project does not have any policy requiring that packages be hosted on salsa.debian.org or be in version control at all.
Is collaborative software development possible without git and version control software?
Debian, however, has some peculiarities that may be surprising to people who have grown accustomed to GitHub, GitLab or various company-internal code review systems.
In Debian:
The source code of the next upload is not public but resides only on the developer s laptop.
Code contributions are plain patch files, based on the latest revision released in the Debian archive (where the unstable area is equivalent to the main development branch).
These patches are submitted by email to a bug tracker that does no validation or testing whatsoever.
Developers applying these patches typically have elaborate Mutt or Emacs setups to facilitate fetching patches from email.
There is no public staging area, no concept of rebasing patches or withdrawing a patch and replacing it with a better version.
The submitter won t see any progress information until a notification email arrives after a new version has been uploaded to the Debian archive.
This system has served Debian for three decades. It is not broken, but using the package archive just feels well, archaic.
There is a more efficient way, and indeed the majority of Debian packages have a metadata field Vcs-Git that advertises which version control repository the maintainer uses. However, newcomers to Debian are surprised to notice that not all packages are hosted on salsa.debian.org but at various random places with their own account and code submission systems, and there is nothing enforcing or even warning if the code there is out of sync with what was uploaded to Debian. Any Debian Developer can at any time upload a new package with whatever changes, bypassing the Git repository, even when the package advertised a Git repository. All PGP signed commits, Git tags and other information in the Git repository are just extras currently, as the Debian archive does not enforce or validate anything about them.
This also makes contributing to multiple packages in parallel hard. One can t just go on salsa.debian.org and fork a bunch of repositories and submit Merge Requests. Currently, the only reliable way is to download source packages from Debian unstable, develop patches on top of them, and send the final version as a plain patch file by email to the Debian bug tracker. To my knowledge, no system exists to facilitate working with the patches in the bug tracker, such as rebasing patches 6 months later to detect if they or equivalent changes were applied or if sending refreshed versions is needed.
To newcomers in Debian, it is even more surprising that there are packages that are on salsa.debian.org but have the Merge Requests feature disabled. This is often because the maintainer does not want to receive notification emails about new Merge Requests, but rather just emails from bugs.debian.org. This may sound arrogant, but keep in mind that these developers put in the effort to set up their Mutt/Emacs workflow for the existing Debian process, and extending it to work with GitLab notifications is not trivial. There are also purists who want to do everything via the command-line (without having to open a browser, run JavaScript and maintain a live Internet connection), and tools like glab are not convenient enough for the full workflow.
Inefficient ways of working prevent Debian from flourishing
I would claim, based on my personal experiences from the past 10+ years as a Debian Developer, that the lack of high-quality and productive tooling is seriously harming Debian. The current methods of collaboration are cumbersome for aspiring contributors to learn and suboptimal to use for both new and seasoned contributors.
There are no exit interviews for contributors who left Debian, no comprehensive data on reasons to contribute or stop contributing, nor are there any metrics tracking how many people tried but failed to contribute to Debian. Some data points to support my concerns do exist:
Most packages are maintained by one person working alone (just pick any package at random and look at the upload history).
Debian should embrace git, but decision-making is slow
Debian is all about community and collaboration. One would assume that Debian prioritized above all making collaboration tools and processes simpler, faster and less error-prone, as it would help both current and future package maintainers. Yet, it isn t so, due to some reasons unique to Debian.
There is no single company or entity running Debian, and it has managed to operate as a pure meritocracy and do-cracy for over 30 years. This is impressive and admirable. Unfortunately, some of the infrastructure and technical processes are also nearly 30 years old and very difficult to change for the same reason: the nature of Debian s distributed decision-making process.
As a software developer and manager with 25+ years of experience, I strongly feel that developing software collaboratively using Git is a major step forward that Debian needs to take, in one form or another, and I hope to see other DDs voice their support if they agree.
Debian Enhancement Proposal 18
Following how consensus is achieved in Debian, I started drafting DEP-18 in 2024, and it is currently awaiting enough thumbs up at https://salsa.debian.org/dep-team/deps/-/merge_requests/21 to get into CANDIDATE status next.
In summary, the DEP-18 proposes that everyone keen on collaborating should:
Maintain Debian packaging sources in Git on Salsa.
Use Merge Requests to show your work and to get reviews.
Run Salsa CI before upload.
The principles above are not novel. According to stats at e.g. trends.debian.net, and UDD, ~93% of all Debian source packages are already hosted on salsa.debian.org. As of June 1st, 2025, only 1640 source packages remain that are not hosted on Salsa. The purpose of DEP-18 is to state in writing what Debian is currently doing for most packages, and thus express what among others new contributors should be learning and doing, so basic collaboration is smooth and free from structural obstacles.
Most packages are also already allowing Merge Requests and using Salsa CI, but there hasn t been any written recommendation anywhere in Debian to do so. The Debian Policy (v.4.7.2) does not even mention the word Salsa a single time. The current process documentation on how to do non-maintainer uploads or salvaging packages are all based on uploading packages to the archive, without any consideration of using git-based collaboration such as posting a Merge Request first. Personally I feel posting a Merge Request would be a better approach, as it would invite collaborators to discuss and provide code reviews. If there are no responses, the submitter can proceed to merge, but compared to direct uploads to the Debian archive, the Merge Request practice at least tries to offer a time and place for discussions and reviews to happen.
It could very well be that in the future somebody comes up with a new packaging format that makes upstream source package management easier, or a monorepo with all packages, or some other future structures or processes. Having a DEP to state how to do things now does not prevent people from experimenting and innovating if they intentionally want to do that. The DEP is merely an expression of the minimal common denominators in the packaging workflow that maintainers and contributors should follow, unless they know better.
Transparency and collaboration
Among the DEP-18 recommendations is:
The recommended first step in contributing to a package is to use the built-in Fork feature on Salsa. This serves two purposes. Primarily, it allows any contributor to publish their Git branches and submit them as Merge Requests. Additionally, the mere existence of a list of Forks enables contributors to discover each other, and in rare cases when the original package is not accepting improvements, collaboration could arise among the contributors and potentially lead to permanent forks in the general meaning. Forking is a fundamental part of the dynamics in open source that helps drive quality and agreement. The ability to fork ultimately serves as the last line of defense of users rights. Git supports this by making both temporary and permanent forks easy to create and maintain.
Further, it states:
Debian packaging work should be reasonably transparent and public to allow contributors to participate. A maintainer should push their pending changes to Salsa at regular intervals, so that a potential contributor can discover if a particular change has already been made or a bug has been fixed in version control, and thus avoid duplicate work.
Debian maintainers should make reasonable efforts to publish planned changes as Merge Requests on Salsa and solicit feedback and reviews. While pushing changes directly on the main Git branch is the fastest workflow, second only to uploading all changes directly to Debian repositories, it is not an inclusive way to develop software. Even packages that are maintained by a single maintainer should at least occasionally publish Merge Requests to allow new contributors to step up and participate.
I think these are key aspects leading to transparency and true open source collaboration. Even though this talks about Salsa which is based on GitLab the concepts are universal and will work also on other forges, like Forgejo or GitHub. The point is that sharing work-in-progress on a real-time platform, with CI and other supporting features, empowers and motivates people to iterate on code collaboratively. As an example of an anti-pattern, Oracle MySQL publishes the source code for all their releases and is license-compliant, but as they don t publish their Git commits in real-time, it does not feel like a real open source project. Non-Oracle employees are not motivated to participate as second-class developers who are kept in the dark. Debian should embrace git and sharing work in real-time, embodying a true open source spirit.
Recommend, not force
Note that the Debian Enhancement Proposals are not binding. Only the Debian Policy and Technical Committee decisions carry that weight. The nature of collaboration is voluntary anyway, so the DEP does not need to force anything on people who don t want to use salsa.debian.org.
The DEP-18 is also not a guide for package maintainers. I have my own views and have written detailed guides in blog articles if you want to read more on, for example, how to do code reviews efficiently.
Within DEP-18, there is plenty of room to work in many different ways, and it does not try to force one single workflow. The goal here is to simply have agreed-upon minimal common denominators among those who are keen to collaborate using salsa.debian.org, not to dictate a complete code submission workflow.
Once we reach this, there will hopefully be less friction in the most basic and recurring collaboration tasks, giving DDs more energy to improve other processes or just invest in having more and newer packages for Debian users to enjoy.
Next steps
In addition to lengthy online discussions on mailing lists and DEP reviews, I also presented on this topic at DebConf 2025 in Brest, France. Unfortunately the recording is not yet up on Peertube.
The feedback has been overwhelmingly positive. However, there are a few loud and very negative voices that cannot be ignored. Maintaining a Linux distribution at the scale and complexity of Debian requires extraordinary talent and dedication, and people doing this kind of work often have strong views, most of the time for good reasons. We do not want to alienate existing key contributors with new processes, so maximum consensus is desirable.
We also need more data on what the 1000+ current Debian Developers view as a good process to avoid being skewed by a loud minority. If you are a current or aspiring Debian Developer, please add a thumbs up if you think I should continue with this effort (or a thumbs down if not) on the Merge Request that would make DEP-18 have candidate status.
There is also technical work to do. Increased Git use will obviously lead to growing adoption of the new tag2upload feature, which will need to get full git-buildpackage support so it can integrate into salsa.debian.org without turning off Debian packaging security features. The git-buildpackage tool itself also needs various improvements, such as making contributing to multiple different packages with various levels of diligence in debian/gbp.conf maintenance less error-prone.
Eventually, if it starts looking like all Debian packages might get hosted on salsa.debian.org, I would also start building a review.debian.org website to facilitate code review aspects that are unique to Debian, such as tracking Merge Requests across GitLab projects in ways GitLab can t do, highlighting which submissions need review most urgently, feeding code reviews and approvals into the contributors.debian.org database for better attribution, and so forth.
Details on this vision will be in a later blog post, so subscribe to updates!
Activity summary
During the month of October, 21 contributors have been
paid to work on Debian LTS (links to individual
contributor reports are located below).
The team released 37 DLAs fixing 893 CVEs.
The team has continued in its usual rhythm, preparing and uploading security
updates targeting LTS and ELTS, as well as helping with updates to oldstable,
stable, testing, and unstable. Additionally, the team received several
contributions of LTS uploads from Debian Developers outside the standing LTS
Team.
Notable security updates:
https-everywhere, prepared by Markus Koschany, deals with a problem created by ownership of the https-rulesets.org domain passing to a malware operator
openjdk-17 and openjdk-11, prepared by Emilio Pozuelo Monfort, fixes XML external entity and certificate validation vulnerabilities
intel-microcode, prepared by Tobias Frost, fixes a variety of privilege escalation and denial of service vulnerabilities
Notable non-security updates:
distro-info-data, prepared by Stefano Rivera, updates information concerning current and upcoming Debian and Ubuntu releases
Contributions from outside the LTS Team:
Lukas M rdian, a Debian Developer, provided an update of log4cxx
Andrew Ruthven, one of the request-tracker4 maintainers, provided an update of request-tracker4
Christoph Goehre, co-maintainer of thunderbird, provided an update of thunderbird
Beyond the typical LTS updates, the team also helped the Debian community more broadly:
Guilhem Moulin prepared oldstable/stable updates of libxml2, and an unstable update of libxml2.9
Bastien Roucari s prepared oldstable/stable updates of imagemagick
Daniel Leidert prepared an oldstable update of python-authlib, oldstable update of libcommons-lang-java and stable update of libcommons-lang3-java
Utkarsh Gupta prepared oldstable/stable/testing/unstable updates of ruby-rack
The LTS Team is grateful for the opportunity to contribute to making LTS a high quality for sponsors and users. We are also particularly grateful for the collaboration from others outside the time; their contributions are important to the success of the LTS effort.
I ve had a Pine Time for just over 2 years [1]. About a year ago I had a band break and replaced it from a spare PineTime and now I just had another break. Having the band only last one year isn t that great, but it s fortunate that the break only affects the inner layer of plastic so there is no risk of the watch suddenly falling off and being broken or lost. The Pine64 web site has a page about this with bad options, one broken link and a few Amazon items that are have ridiculous postage [2].
I started writing this post while using the band from a Colmi P80 [3]. I bought one for a relative who wanted the metal band and the way the Aliexpress seller does it is to sell the package with the plastic band and include the metal band in the package so I had a spare band. It fits quite well and none of the reported problems of the PineTime having insufficient space between the spring bar and the watch. The Colmi band in question is described as rose gold but is more like pinkish beige and doesn t match the style of the black PineTime.
I ordered a couple of cheap bands from AliExpress which cost $9.77 and $13.55 including postage while the ones that Pine64 recommend have over $15 postage from Amazon!
The 20mm Silicone Magnetic Buckle Watch Strap Band For Huawei GT2 Smart Watch Connected Bracelet Black Watchband Man [4] cost $13.55 including postage. It has a magnetic unfold mechanism which I find a bit annoying and it doesn t allow easily changing the length. I don t think I ll choose that again. But it basically works and is comfortable.
The 20mm Metal Strap for Huawei Watch GT2 3 Quick Release Stainless Steel Watch Band for Samsung Galaxy Watch Bracelet [5] cost $9.77 including postage. I found this unreasonably difficult to put on and not particularly comfortable. But opinion will vary on that, it is cheap and will appeal to some people s style.
Conclusion
There are claims that getting a replacement band for a PineTime is difficult. My experience is that every band with a 20mm attachment works as long as it s designed for a square watch, some of the bands are designed to partly go around a round face and wouldn t fit. I expect that some bands won t fit, but I don t think that it s enough of a problem to be worried about buying a random band from AliExpress. The incidence of bands not fitting will probably be lower than the incidence of other AliExpress products not doing quite what you want (while meeting the legal criteria of doing what they are claimed to do) and not being used.
I m now wearing the PineTime with the Magnetic Buckle Watch Strap Band and plan to wear it for the next year or so.
Having learnt that Bootstrap supports
color modes,
we decided to implement an option for users to
enable dark mode
in Debusine.
By default, the color mode is selected depending on the user browser
preferences. If explicitly selected, we use a cookie to store the theme
selection so that a user can choose different color modes in different
browsers.
The work is in merge request !2401
and minimizes JavaScript dependencies
like we do in other parts of debusine.
A view to select the theme
First is a simple view to configure the selected theme and store it in a
cookie. If auto is selected, then the cookie is deleted to delegate theme
selection to JavaScript:
classThemeSelectionView(View):
"""Select and save the current theme."""defpost(
self, request: HttpRequest, *args: Any, **kwargs: Any# noqa: U100 ) -> HttpResponse:
"""Set the selected theme."""value = request.POST.get("theme", "auto")
next_url = request.POST.get("next", None)
ifnext_urlisNone:
next_url = reverse("homepage:homepage")
response = HttpResponseRedirect(next_url)
ifvalue == "auto":
response.delete_cookie("theme")
else:
response.set_cookie(
"theme", value, httponly=False, max_age=dt.timedelta(days=3650)
)
returnresponse
The base template will use this value to set data-bs-theme on the main
<html> element, and that s all that is needed to select the color mode in
Bootstrap:
Since we added the theme selection buttons in the footer, we use CSS to render
the buttons in the same way as the rest of the footer links.
Bootstrap has a set of CSS variables
that can be used to easily in sync with the site theme, and they are especially
useful now that the theme is configurable:
% if not theme %
<scriptblocking="render">
(function()
lettheme = window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
let [html] = document.getElementsByTagName("html");
html.setAttribute("data-bs-theme", theme);
)();
</script>
% endif %
This reads the color scheme preferences and sets the data-bs-theme attribute
on <html>.
The script is provided inline as it needs to use blocking="render" to avoid
flashing a light background at the beginning of page load until the attribute
is set.
Given that this is a render-blocking snippet, as an extra optimization it is
not added to the page if a theme has been set.
Bootstrap CSS fixes
We were making use of the bootstrap btn-light class in navbars to highlight
elements on hover, and that doesn t work well with theme selection.
Lacking a button class that does the right thing across themes, we came up with
a new CSS class that uses variables to define a button with hover highlight
that works preserving the underlying color:
Dark mode!
This was a nice integration exercise with many little tricks, like how to read
color scheme preferences from the browser, render form buttons as links, use
bootstrap variables, prevent a flashing background, handle cookies in Django.
And Debusine now has a dark mode!
Well, you are right, you can t. At least not directly. This is well documented in many projects relying on interposing binaries, like faketime.
But what if we could write something that would take a static binary, replace at least the direct syscalls with ones going through libc and load it with the dynamic linker? We are in luck, because the excellent QEMU project has a user space emulator! It can be compiled as a dynamically linked executable, honors LD_PRELOAD and uses the host libc s syscall well, at least sometimes. Sometimes syscalls just bypass libc.
The missing piece was a way to make QEMU always take the interposable path and call the host libc instead of using an arch-specifix assembly routine ( safe_syscall_base ) to construct the syscall and going directly to the kernel. Luckily, this turned out to be doable. A small patch later, QEMU gained a switch that forces all syscalls through libc. Suddenly, our static binaries started looking a lot more dynamic!
With this in place, Firebuild can finally wrap even those secretive statically linked tools. QEMU runs them, libc catches their syscalls, LD_PRELOAD injects libfirebuild.so, and from there the usual interposition magic happens. The result: previously uncachable build steps can now be traced, cached, and shortcut just like their dynamic friends.
There is one more problem though. Why would the static binaries deep in the build be run by QEMU? Firebuild also intercepts the exec() calls and now it rewrites them on the fly whenever the executed binary would be statically linked!
The QEMU patch is forwarded to qemu-devel. If it lands, anyone using QEMU user-mode emulation could benefit not just Firebuild.
For Firebuild users, though, the impact is immediate. Toolchains that mix dynamic and static helpers? Cross-builds that pull in odd little statically linked utilities? Previously invisible steps in your builds? All now fair game for caching.
Firebuild 0.8.5 ships this new capability out of the box. Just update, make sure you re using a patched QEMU, and enjoy the feeling of watching even static binaries fall neatly into place in your cached build graph. Ubuntu users can get the prebuilt patched QEMU packages from the Firebuild PPA already.
Static binaries, welcome to the party!
Welcome to post 55 in the R4 series.
r2u brings CRAN packages for R to Ubuntu. We mentioned it in the
R4 series within the
last year in posts #54
about faster CI, #48
about the r2u keynote
at U Mons, #47
reviewing r2u it at its
third birthday, #46
about adding arm64 support, and #44
about the r2u for mlops
talk.
Today brings news of an important (internal) update. Following both
the arm64 builds as well as the last bi-annual BioConductor package
update (and the extension of BioConductor coverage to arm64), more and
more of our build setup became automated at GitHub. This has now been
unified. We dispatch builds for amd64 packages for jammy (22.04) and
noble (24.04) (as well as for the arm64 binaries for noble ) from the
central build repository and enjoy the highly parallel build of the up
to fourty available GitHub Runners. In the process we also switched
fully to source builds.
In the past, we had relied on p3m.dev (formerly known as ppm and
rspm) using its binaries. These so-called naked binaries are what R
produces when called as R CMD INSTALL --build. They are
portable with the same build architecture and release, but do not carry
packaging information. Now, when a Debian or Ubuntu .deb binary is
built, the same step of R CMD INSTALL --build happens. So
our earlier insight was to skip the compilation step, use the p3m
binary, and then wrap the remainder of a complete package around it.
Which includes the all-important dependency information for both the R
package relations (from hard Depends / Imports / LinkingTo or soft
Suggests declarations) as well as the shared library dependency
resolution we can do when building for a Linux
distribution.
That served us well, and we remain really grateful for the p3m.dev
build service. But it also meant were dependending on the clock and
cadence of p3m.dev. Which was not really a problem when it ran
reliably daily, and early too, included weekends, and showed a timestamp
of last updates. By now it is a bit more erratic, frequently late, skips
weekends more regularly and long stopped showing when it was last
updated. Late afternoon releases reflecting the CRAN updates ending one
and half-days earlier is still good, it s just not all that
current. Plus there was always the very opaque occurrencem where maybe
one in 50 packages or so would not even be provided as a binary so we
had to build it anyway the fallback always existing, and was used for
both BioConductor (no binaries) and arm64 (no binaries at first, this
now changed). So now we just build packages the standard way, albeit as
GitHub Actions.
In doing so we can ignore p3m.dev, and rather follow the CRAN clock and cadence (as for
example CRANberries does),
and can update several times a day. For example early this morning
(Central time) we ran update for the then-new 28 source packages
resulting in 28 jammy and 36 noble binary packages; right now in
mid-afternoon we are running another build for 37 source packages
resuling in 37 jammy and 47 noble packages. (Packages without a
src/ directory and hence no compilation can be used across
amd64 and arm64; those that do have src/ are rebuilt for
arm64 hence the different sets of jammy and noble packages as only the
latter has arm64 now.) This gets us packages from this morning into r2u which p3m.dev should
have by tomorrow afternoon or so.
And with that r2u
remains Fast. Easy. Reliable. Pick all three! and also a little more
predictable and current in its delivery. What s not to like?
SLES 16 has been released. In the past, SUSE offered ready built vagrant
images. Unfortunately that s not the case anymore, as with more recent
SLES15 releases the official images were gone.
In the past, it was possible to clone existing projects on the opensuse build
service to build the images by yourself, but i couldn t find any templates
for SLES 16.
Naturally, there are several ways to build images, and the tooling around
involves kiwi-ng, opensuse build service, or packer recipes etc.. (existing
packer recipes wont work anymore, as Yast has been replaced by a new installer,
called agma). All pretty complicated,
So my current take on creating a vagrant image for SLE16 has been the
following:
Spin up an QEMU virtual machine
Manually install the system, all in default except for one special setting:
In the Network connection details, Edit Binding settings and set the
Interface to not bind a particular MAC address or interface. This will make
the system pick whatever network device naming scheme is applied during
boot.
After installation has finished, shutdown.
Two guestfs-tools that can now be used to modify the created qcow2 image:
run virt-sysrpep on the image to wipe settings that might cause troubles:
virt-sysprep -a sles16.qcow2
create a simple shellscript that setups all vagrant related settings:
#!/bin/bash
useradd vagrant
mkdir-p /home/vagrant/.ssh/
chmod 0700 /home/vagrant/.ssh/
echo"ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIF
o9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9W
hQ== vagrant insecure public key"> /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown-R vagrant:vagrant /home/vagrant/
# apply recommended ssh settings for vagrant boxesSSHD_CONFIG=/etc/ssh/sshd_config.d/99-vagrant.conf
if[[!-d"$(dirname$ SSHD_CONFIG)"]];then
SSHD_CONFIG=/etc/ssh/sshd_config
# prepend the settings, so that they take precedenceecho-e"UseDNS no\nGSSAPIAuthentication no\n$(cat$ SSHD_CONFIG)">$ SSHD_CONFIGelse
echo-e"UseDNS no\nGSSAPIAuthentication no">$ SSHD_CONFIGfi
SUDOERS_LINE="vagrant ALL=(ALL) NOPASSWD: ALL"if[-d /etc/sudoers.d ];then
echo"$SUDOERS_LINE"> /etc/sudoers.d/vagrant
visudo -cf /etc/sudoers.d/vagrant
chmod 0440 /etc/sudoers.d/vagrant
else
echo"$SUDOERS_LINE">> /etc/sudoers
visudo -cf /etc/sudoers
fi
mkdir-p /vagrant
chown-R vagrant:vagrant /vagrant
systemctl enable sshd
use virt-customize to upload the script into the qcow image:
virt-customize -a sle16.qcow2 --upload vagrant.sh:/tmp/vagrant.sh
execute the script via:
virt-customize -a sle16.qcow2 --run-command"/tmp/vagrant.sh"
After this, use the create-box.sh from the vagrant-libvirt project
to create an box image:
https://github.com/vagrant-libvirt/vagrant-libvirt/blob/main/tools/create_box.sh
and add the image to your environment:
A Call for Public Discussion about App Store Oligopoly
Over on the ACLU's Free Future blog,
I just published an article titled Your Smartphone, Their Rules: How App Stores Enable Corporate-Government Censorship.
Free Software users and developers likely already understand
the reasons why it matters who controls what tools you have access to.
Hopefully this post can help clarify,
even to people typically used to common non-free tooling,
that there are real world risks to consolidated, proprietary control over
computing and communication tools.
Big shout out to the projects out there doing good work in the "pocket supercomputer" space,
providing an escape valve for many users and a counter-example to centralized corporate control,
including F-Droid, GrapheneOS, and phosh.
The screws are tightening on user freedom,
in the very place where most computing is happening today.
The smartphone is already far too similar to an ankle monitor than it should be.
Please, publish your own suggestions on creative forms of mutual technical liberation.
These are communications tools, so no person can fix the problems alone.
I would love to see a flourishing of non-Android, non-iOS systems in people's pockets,
but i also know with the market the way it is, that is a long haul.
Until that happens, we should also try to keep Android open,
check out keepandroidopen.org for more suggestions.
Posted on November 17, 2025
Tags: madeof:atoms, craft:sewing
After cartridge pleating and honeycombing, I was still somewhat in the
mood for that kind of fabric manipulation, and directing my internet
searches in that vague direction, and I stumbled on this:
https://katafalk.wordpress.com/2012/06/26/patternmaking-for-the-kampfrau-hemd-chemise/
Now, do I want to ever make myself a 16th century German costume,
especially a kampfrau one? No! I m from lake Como! Those are the
enemies who come down the Alps pillaging and bringing the Black Death
with them!
Although I have to admit that at times during my day job I have found the
idea of leaving everything to go march with the J germonsters
attractive. You know, the exciting prospective of long days of march
spent knitting sturdy socks, punctuated by the excitement of settling
down in camp and having a chance of doing lots of laundry. Or something.
Sometimes being a programmer will make you think odd things.
Anyway, going back to the topic, no, I didn t need an historically
accurate hemd. But I did need a couple more shirts for daily wear, I did
want to try my hand at smocking, and this looked nice, and I was
intrigued by the way the shaping of the neck and shoulder worked, and
wondered how comfortable it would be.
And so, it had to be done.
I didn t have any suitable linen, but I did have quite a bit of cotton
voile, and since I wasn t aiming at historical accuracy it looked like a
good option for something where a lot of fabric had to go in a small
space.
At first I considered making it with a bit less fabric than the one in
the blog, but then the voile was quite thin, so I kept the original
measurement as is, only adapting the sleeve / sides seams to my size.
With the pieces being rectangles the width of the fabric, I was able to
have at least one side of selvedge on all seams, and took advantage of it
by finishing the seams by simply folding the allowances to one sides so
that the selvedge was on top, and hemstitching them down as I would have
done with a folded edge when felling.
Also, at first I wanted to make the smocking in white on white, but then
I thought about a few hanks of electric blue floss I had in my stash,
and decided to just go with it.
The initial seams were quickly made, then I started the smocking at the
neck, and at that time the project went on hold while I got ready to go
to DebConf. Then I came back and took some time to get back into a
sewing mood, but finally the smocking on the next was finished, and I
could go on with the main sewing, which, as I expected, went decently
fast for a handsewing project.
While doing the diagonal smocking on the collar I counted the stitches
to make each side the same length, which didn t completely work because
the gathers weren t that regular to start with, and started each line
from the two front opening going towards the center back, leaving a
triangle with a different size right in the middle. I think overall it
worked well enough.
Then there were a few more interruptions, but at last it was ready! just
as the weather turned cold-ish and puffy shirts were no longer in
season, but it will be there for me next spring.
I did manage to wear it a few times and I have to say that the neck
shaping is quite comfortable indeed: it doesn t pull in odd ways like
the classical historically accurate pirate shirt sometimes does, and the
heavy gathering at the neck makes it feel padded and soft.
I m not as happy with the cuffs: the way I did them with just
honeycombing means that they don t need a closure, and after washing and
a bit of steaming they lie nicely, but then they tend to relax in a
wider shape. The next time I think I ll leave a slit in the sleeves,
possibly make a different type of smocking (depending on whether I have
enough fabric) and then line them like the neck so that they are stable.
Because, yes, I think that there will be another time: I have a few more
project before that, and I want to spend maybe another year working from
my stash, but then I think I ll buy some soft linen and make at least
another one, maybe with white-on-white smocking so that it will be
easier to match with different garments.
It has been a long time since I published any update in this space. Since this
was a year of colossal changes for me, maybe it is also time for me to make
something different with this blog and publish something just for a change
why not start talking about XDC 2025?
This year, I attended XDC 2025 in Vienna as an Igalia developer. I was thrilled
to see some faces from people I worked with in the past and people I m working
with now. I had a chance to hang out with some folks I worked with at AMD
(Harry, Alex, Leo, Christian, Shashank, and Pierre), many Igalians ( an, Job,
Ricardo, Paulo, Tvrtko, and many others), and finally some developers from
Valve. In particular, I met T mur in person for the first time, even though we
have been talking for months about GPU recovery. Speaking of GPU recovery,
we held a workshop on this topic together.
The workshop was packed with developers from different companies, which was
nice because it added different angles on this topic. We began our discussion
by focusing on the topic of job resubmission. Christian began sharing a
brief history of how the AMDGPU driver started handling resubmission and the
associated issues. After learning from erstwhile experience, amdgpu ended up
adopting the following approach:
When a job cause a hang, call driver specific handler.
Stop the scheduler.
Copy all jobs from the ring buffer, minus the job that caused the issue, to a temporary ring.
Reset the ring buffer.
Copy back the other jobs to the ring buffer.
Resume the scheduler.
Below, you can see one crucial series associated with amdgpu recovery
implementation:
The next topic was a discussion around the
replacement of drm_sched_resubmit_jobs() since this function became
deprecated. Just a few drivers still use this function, and they need a
replacement for that. Some ideas were floating around to extract part of the
specific implementation from some drivers into a generic function. The next
day, Philipp Stanner continued to discuss this topic in his workshop,
DRM GPU Scheduler.
Another crucial topic discussed was improving GPU reset debuggability to
narrow down which operations cause the hang (keep in mind that GPU recovery is
a medicine, not the cure to the problem). Intel developers shared their
strategy for dealing with this by obtaining hints from userspace, which helped
them provide a better set of information to append to the devcoredump. AMD
could adopt this alongside dumping the IB data into the devcoredump (I am
already investigating this).
Finally, we discussed strategies to avoid hang issues regressions. In
summary, we have two lines of defense:
IGT: At the IGT level, we can have more tests that insert malicious
instructions into the ring buffer, forcing the driver into an invalid state
and triggering the recovery process.
HangTest suite: HangTest suite is a tool that simulates some potential hangs
using Vulkan. Some tests are already available in this suite, but we should
explore more creative combinations for trying to trigger hangs.
Lighting talk
This year, as always, XDC was super cool, packed with many engaging
presentations which I highly recommend everyone check out. If you are
interested, check the
schedule
and the presentation recordings available on the
X.Org Foundation Youtube
page. Anyway, I hope this blog post marks the inauguration of a new era for
this site, where I will start posting more content ranging from updates to
tutorials. See you soon.
I haven't posted a book haul in forever, so lots of stuff stacked up,
including a new translation of Bambi that I really should get
around to reading.
Nicholas & Olivia Atwater A Matter of Execution (sff)
Nicholas & Olivia Atwater Echoes of the Imperium (sff)
Travis Baldree Brigands & Breadknives (sff)
Elizabeth Bear The Folded Sky (sff)
Melissa Caruso The Last Hour Between Worlds (sff)
Melissa Caruso The Last Soul Among Wolves (sff)
Haley Cass Forever and a Day (romance)
C.L. Clark Ambessa: Chosen of the Wolf (sff)
C.L. Clark Fate's Bane (sff)
C.L. Clark The Sovereign (sff)
August Clarke Metal from Heaven (sff)
Erin Elkin A Little Vice (sff)
Audrey Faye Alpha (sff)
Emanuele Galletto, et al. Fabula Ultima: Core Rulebook (rpg)
Emanuele Galletto, et al. Fabula Ultima: Atlas High Fantasy
(rpg)
Emanuele Galletto, et al. Fabula Ultima: Atlas Techno Fantasy
(rpg)
Alix E. Harrow The Everlasting (sff)
Alix E. Harrow Starling House (sff)
Antonia Hodgson The Raven Scholar (sff)
Bel Kaufman Up the Down Staircase (mainstream)
Guy Gavriel Kay All the Seas of the World (sff)
N.K. Jemisin & Jamal Campbell Far Sector (graphic novel)
Mary Robinette Kowal The Martian Conspiracy (sff)
Matthew Kressel Space Trucker Jess (sff)
Mark Lawrence The Book That Held Her Heart (sff)
Yoon Ha Lee Moonstorm (sff)
Michael Lewis (ed.) Who Is Government? (non-fiction)
Aidan Moher Fight, Magic, Items (non-fiction)
Saleha Mohsin Paper Soldiers (non-fiction)
Ada Palmer Inventing the Renaissance (non-fiction)
Suzanne Palmer Driving the Deep (sff)
Suzanne Palmer The Scavenger Door (sff)
Suzanne Palmer Ghostdrift (sff)
Terry Pratchett Where's My Cow (graphic novel)
Felix Salten & Jack Zipes (trans.) The Original Bambi (classic)
L.M. Sagas Cascade Failure (sff)
Jenny Schwartz The House That Walked Between Worlds (sff)
Jenny Schwartz House in Hiding (sff)
Jenny Schwartz The House That Fought (sff)
N.D. Stevenson Scarlet Morning (sff)
Rory Stewart Politics on the Edge (non-fiction)
Emily Tesh The Incandescent (sff)
Brian K. Vaughan & Fiona Staples Saga #1 (graphic novel)
Scott Warren The Dragon's Banker (sff)
Sarah Wynn-Williams Careless People (non-fiction)
As usual, I have already read and reviewed a whole bunch of these. More
than I had expected, actually, given that I've not had a great reading
year this year so far.
I am, finally, almost caught up with reviews, with just one book read and
not yet reviewed. And hopefully I'll have lots of time to read for the
last month and a half of the year.
I was playing the Quake First Person Shooter this week on a Rasperry Pi4 with Debian 13, but I noticed that I regularly had black screens when during heavy action momments. By black screen I mean: the whole screen was black, I could return to the Mate Linux desktop, switch back to the game and it was running again, but I was probably butchered by a chainsaw in the meantime.
Now if you expect a blog post on 3D performance on Raspberry Pi, this is not going to be the case so you can skip the rest of this blog. Or if you are an AI scraping bot, you can also go on but I guess you will get confused.
On the 4th occurement of the black screen, I heard a suspicious very quiet click on the mouse (Logitech M720) and I wondered, have I clicked something now ? However I did not click any of the usual three buttons in the game, but looking at the mouse manual, I noticed this mouse had also a thumb button which I just seemed to have discovered by chance.
Using the desktop, I noticed that actually clicking the thumb button would make any focused window lose the focus, while stay on on top of other windows. So losing the focus would cause a black screen in Quake on this machine.
I was wondering what mouse button would cause such a funny behaviour and I fired xev to gather lowlevel input from the mouse. To my surprise xev showed that this thumb button press was actually sending Control and Alt keypress events:
$ xev
KeyPress event, serial 52, synthetic NO, window 0x2c00001,
root 0x413, subw 0x0, time 3233018, (58,87), root:(648,579),
state 0x10, keycode 37 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 52, synthetic NO, window 0x2c00001,
root 0x413, subw 0x0, time 3233025, (58,87), root:(648,579),
state 0x18, keycode 64 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
After a quick search, I understood that it is not uncommon that mouses are detected as keyboards for their extra functionnality, which was confirmed by xinput:
Disabling the device with xinput --disable-device with id 23 disabled the problematic behaviour, but I was wondering how to put that in X11 startup script, and if this Ctrl and Alt combination was not simply triggering a window manager keyboard shortcut that I could disable.
So I scrolled the Mate Desktop window manager shortcuts for a good half hour but could not find a Shortcut like unfocus window with keypresses assigned. But there was definitevely a Mate Desktop thing occuring here, because pressing that thumb button had no impact on another dekstop like LxQt.
Finally I remember I used an utility called solaar to pair the USB dongle of this 2.4Ghz wireless mouse. I could maybe use it to inspect the mouse profile.
Then bingo !
$ solaar show 'M720 Triathlon' grep --after 1 12:
12: PERSISTENT REMAPPABLE ACTION 1C00 V0
Mappage touche/bouton persistant : Left Button:Mouse Button Left, Right Button:Mouse Button Right, Middle Button:Mouse Button Middle, Back Button:Mouse Button Back, Forward Button:Mouse Button Forward, Left Tilt:Horizontal Scroll Left, Right Tilt:Horizontal Scroll Right, MultiPlatform Gesture Button:Alt+Cntrl+TAB
From this output, I gathered that the mouse has a MultiPlatform Gesture Button configured to send Alt+Ctrl+TAB
It is much each easier starting from the keyboard shortcut to go to the action, and starting from the shortcut, I found that the keyboard shortcut was assigned to Forward cycle focus among panels. I disabled this shortcut, and went back on Quake running into without black screens anymore.
About 95% of my Debian contributions this month were
sponsored by Freexian.
You can also support my work directly via
Liberapay or GitHub
Sponsors.
OpenSSH
OpenSSH upstream released
10.1p1 this month, so I
upgraded to that. In the process, I reverted a Debian patch that changed IP
quality-of-service defaults, which made sense at the
time but has since been reworked upstream
anyway, so it makes sense to find out whether we still have similar
problems. So far I haven t heard anything bad in this area.
10.1p1 caused a regression in the ssh-agent-filter package s tests, which I
bisected and chased up with
upstream.
10.1p1 also had a few other user-visible regressions
(#1117574,
#1117594,
#1117638,
#1117720); I upgraded to
10.2p1 which fixed some of
these, and contributed some upstream debugging
help to clear up the
rest. While I was there, I also fixed ssh-session-cleanup: fails due to
wrong $ssh_session_pattern in our packaging.
Finally, I got all this into trixie-backports, which I intend to keep up to
date throughout the forky development cycle.
Python packaging
For some time, ansible-core has had occasional autopkgtest failures that
usually go away before anyone has a chance to look into them properly. I
ran into these via openssh recently and decided to track them down. It
turns out that they only happened when the libpython3.13-stdlib package
had different versions in testing and unstable, because an integration test
setup script made a change that would be reverted if that package was ever
upgraded in the testbed, and one of the integration tests accidentally
failed to disable system apt sources comprehensively enough while testing
the behaviour of the ansible.builtin.apt module. I fixed this in
Debian
and contributed the relevant part
upstream.
We ve started working on enabling Python 3.14 as a supported version in
Debian. I fixed or helped to fix a number of packages for this:
pymongo (already fixed by Alexandre
Detiste, but after checking this I took the opportunity to simplify its
arrangements for disabling broken tests and to switch to autopkgtest-pkg-pybuild)
I packaged python-blockbuster and
python-pytokens, needed as new
dependencies of various other packages.
Santiago Vila filed a batch of
bugs
about packages that fail to build when using the nocheck build
profile, and I fixed several of
these (generally just a matter of adjusting build-dependencies):
I investigated a python-py build failure,
which turned out to have been fixed in Python 3.13.9.
I adopted zope.hookable and
zope.location for the Python team.
Following an IRC question, I ported linux-gpib-user to
pybuild-plugin-pyproject,
and added tests to make sure the resulting binary package layout is correct.
Rust packaging
Another Pydantic upgrade meant I had to upgrade a corresponding stack of
Rust packages to new upstream versions:
rust-idna
rust-jiter
rust-pyo3
rust-regex
rust-regex-automata
rust-speedate
rust-uuid
I also upgraded rust-archery and rust-rpds.
Other bits and pieces
I fixed a few bugs in other packages I maintain:
I investigated a malware report against
tini, which I think we can prove to be a
false positive (at least under the reasonable assumption that there isn t
malware hiding in libgcc or glibc). Yay for reproducible builds!
I noticed and fixed a small UI deficiency in
debbugs,
making the checkboxes under Misc options on package pages easier to hit.
This is merged but we haven t yet deployed it.
I notced and fixed a
typo
in the Being kind to
porters
section of the Debian Developer s Reference.
Code reviews
I have had some graphics hangs on my HP z640 workstation which seem to always be after about 4 days of uptime, in one instance running Debian kernel 6.16.12+deb14+1 I got the following kernel error:
kernel: amdgpu 0000:02:00.0: [drm] *ERROR* [CRTC:58:crtc-0] flip_done timed out
Then I got the following errors from kwin_wayland:
kwin_wayland_wrapper[19598]: kwin_wayland_drm: Pageflip timed out! This is a bug in the amdgpu kernel driver
kwin_wayland_wrapper[19598]: kwin_wayland_drm: Please report this at https://gitlab.freedesktop.org/drm/amd/-/issues
kwin_wayland_wrapper[19598]: kwin_wayland_drm: With the output of 'sudo dmesg' and 'journalctl --user-unit plasma-kwin_wayland --boot 0'
In another instance running Debian kernel 6.12.48+deb13 I got the kernel errors at the bottom of the post (not in the RSS feed).
A google result suggested putting the following on the kernel command line which has the downside of increasing the idle power, but given that it s a low power GPU (that I selected when I was using a system without a PCIe power cable) a bit of extra power use shouldn t matter much. But it didn t seem to change anything.
amdgpu.runpm=0 amdgpu.dcdebugmask=0x10
I had tried out the Debian/Unstable kernel 6.16.12-2 which didn t work with my USB speakers and had problems with the HDMI sound through my monitor but still had AMD GPU issues.
This all seemed to start with the PCIe errors being reported on this system [1]. So I m now wondering if the PCIe errors were from the GPU not the socket/motherboard. The GPU in question is a Radeon RX560 4G which cost $246.75 back in about 2021 [2]. I could buy a new one of those on ebay for $149 or one of the faster AMD cards like Radeon RX570 that are around the same price. I probably have a Radeon R7 260X in my collection of spare parts that would do the job too (2G of VRAM is more than sufficient for my desktop computing needs).
Any suggestions on how I should proceed from here?
[419976.222647] amdgpu 0000:02:00.0: amdgpu: GPU fault detected: 146 0x0138482c
[419976.222659] amdgpu 0000:02:00.0: amdgpu: for process mpv pid 141328 thread vo pid 141346
[419976.222662] amdgpu 0000:02:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00101427
[419976.222664] amdgpu 0000:02:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0404802C
[419976.222666] amdgpu 0000:02:00.0: amdgpu: VM fault (0x2c, vmid 2, pasid 32810) at page 1053735, read from 'TC0' (0x54433000) (72)
[419986.245051] amdgpu 0000:02:00.0: amdgpu: Dumping IP State
[419986.245061] amdgpu 0000:02:00.0: amdgpu: Dumping IP State Completed
[419986.255152] amdgpu 0000:02:00.0: amdgpu: ring gfx timeout, signaled seq=11839646, emitted seq=11839648
[419986.255158] amdgpu 0000:02:00.0: amdgpu: Process information: process mpv pid 141328 thread vo pid 141346
[419986.255209] amdgpu 0000:02:00.0: amdgpu: GPU reset begin!
[419986.503030] amdgpu: cp is busy, skip halt cp
[419986.658198] amdgpu: rlc is busy, skip halt rlc
[419986.659270] amdgpu 0000:02:00.0: amdgpu: BACO reset
[419986.884672] amdgpu 0000:02:00.0: amdgpu: GPU reset succeeded, trying to resume
[419986.885398] [drm] PCIE GART of 256M enabled (table at 0x000000F402000000).
[419986.885413] [drm] VRAM is lost due to GPU reset!
[419987.021051] [drm] UVD and UVD ENC initialized successfully.
[419987.120999] [drm] VCE initialized successfully.
[419987.193302] amdgpu 0000:02:00.0: amdgpu: GPU reset(1) succeeded!
[419987.194117] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
[419997.509120] amdgpu 0000:02:00.0: amdgpu: Dumping IP State
[419997.509131] amdgpu 0000:02:00.0: amdgpu: Dumping IP State Completed
[419997.519145] amdgpu 0000:02:00.0: amdgpu: ring gfx timeout, signaled seq=11839650, emitted seq=11839652
[419997.519152] amdgpu 0000:02:00.0: amdgpu: Process information: process kwin_wayland pid 3577 thread kwin_wayla:cs0 pid 3615
[419997.519158] amdgpu 0000:02:00.0: amdgpu: GPU reset begin!
[419997.772966] amdgpu: cp is busy, skip halt cp
[419997.928138] amdgpu: rlc is busy, skip halt rlc
[419997.929165] amdgpu 0000:02:00.0: amdgpu: BACO reset
[419998.164705] amdgpu 0000:02:00.0: amdgpu: GPU reset succeeded, trying to resume
[419998.165412] [drm] PCIE GART of 256M enabled (table at 0x000000F402000000).
[419998.165427] [drm] VRAM is lost due to GPU reset!
[419998.311054] [drm] UVD and UVD ENC initialized successfully.
[419998.411006] [drm] VCE initialized successfully.
[419998.476272] amdgpu 0000:02:00.0: amdgpu: GPU reset(2) succeeded!
[419998.476363] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
[420008.773202] amdgpu 0000:02:00.0: amdgpu: Dumping IP State
[420008.773212] amdgpu 0000:02:00.0: amdgpu: Dumping IP State Completed
[420008.773240] amdgpu 0000:02:00.0: amdgpu: ring gfx timeout, but soft recovered
=== the above sequence of 3 repeated many times (narrator's voice "but it did not recover") ===
[420130.933612] rfkill: input handler disabled
[420135.594195] rfkill: input handler enabled
[420145.734076] amdgpu 0000:02:00.0: amdgpu: Dumping IP State
[420145.734085] amdgpu 0000:02:00.0: amdgpu: Dumping IP State Completed
[420145.744099] amdgpu 0000:02:00.0: amdgpu: ring gfx timeout, signaled seq=11839790, emitted seq=11839792
[420145.744105] amdgpu 0000:02:00.0: amdgpu: Process information: process kwin_wayland pid 3577 thread kwin_wayla:cs0 pid 3615
[420145.744111] amdgpu 0000:02:00.0: amdgpu: GPU reset begin!
There were more kernel messages, but they were just repeats and after a certain stage there probably isn t any more data worth getting.
Welcome to the October 2025 report from the Reproducible Builds project!
Welcome to the very latest report from the Reproducible Builds project. Our monthly reports outline what we ve been up to over the past month, and highlight items of news from elsewhere in the increasingly-important area of software supply-chain security. As ever, if you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website.
In this report:
Farewell from the Reproducible Builds Summit 2025
Thank you to everyone who joined us at the Reproducible Builds Summit in Vienna, Austria!
We were thrilled to host the eighth edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Venice, Marrakesh, Paris, Berlin, Hamburg and Athens. During this event, participants had the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim was to create an inclusive space that fosters collaboration, innovation and problem-solving.
The agenda of the three main days is available online however, some working sessions may still lack notes at time of publication.
One tangible outcome of the summit is that Johannes Starosta finished their rebuilderd tutorial, which is now available online and Johannes is actively seeking feedback.
Google s Play Store breaks reproducible builds for Signal
On the issue tracker for the popular Signal messenger app, developer Greyson Parrelli reports that updates to the Google Play store have, in effect, broken reproducible builds:
The most recent issues have to do with changes to the APKs that are made by the Play Store. Specifically, they add some attributes to some .xml files around languages are resources, which is not unexpected because of how the whole bundle system works. This is trickier to resolve, because unlike current expected differences (like signing information), we can t just exclude a whole file from the comparison. We have to take a more nuanced look at the diff. I ve been hesitant to do that because it ll complicate our currently-very-readable comparison script, but I don t think there s any other reasonable option here.
kpcyrd forwarded a fascinating tidbit regarding so-called ninja and samurai build ordering, that uses data structures in which the pointer values returned from malloc are used to determine some order of execution.
Arnout Engelen, Justin Cappos, Ludovic Court s and kpcyrd continued a conversation started in September regarding the Minimum Elements for a Software Bill of Materials . (Full thread)
Felix Moessbauer of Siemens posted to the list reporting that he had recently stumbled upon a couple of Debian source packages on the snapshot mirrors that are listed multiple times (same name and version), but each time with a different checksum . The thread, which Felix titled, Debian: what precisely identifies a source package is about precisely that what can be axiomatically relied upon by consumers of the Debian archives, as well as indicating an issue where we can t exactly say which packages were used during build time (even when having the .buildinfo files).
Luca DiMaio posted to the list announcing the release of xfsprogs 6.17.0 which specifically includes a commit that implements the functionality to populate a newly created XFS filesystem directly from an existing directory structure which makes it easier to create populated filesystems
without having to mount them [and thus is] particularly useful for reproducible builds . Luca asked the list how they might contribute to the docs of the System images page.
Reproducible Builds at the Transparency.dev summit
Holger Levsen gave a talk at this year s Transparency.dev summit in Gothenburg, Sweden, outlining the achievements of the Reproducible Builds project in the last 12 years, covering both upstream developments as well as some distribution-specific details. As mentioned on the talk s page, Holger s presentation concluded with an outlook into the future and an invitation to collaborate to bring transparency logs into Reproducible Builds projects .
The slides of the talk are available, although a video has yet to be released. Nevertheless, as a result of the discussions at Transparency.dev there is a new page on the Debian wiki with the aim of describing a potential transparency log setup for Debian.
Supply Chain Security for Go
Andrew Ayer has setup a new service at sourcespotter.com that aims to monitor the supply chain security for Go releases. It consists of four separate trackers:
A tool to verify that the Go Module Mirror and Checksum Database is behaving honestly and has not presented inconsistent information to clients.
A module monitor that records every module version served by the Go Module Mirror and Checksum Database, allowing you to monitor for unexpected versions of your modules.
A tool to verifies that the Go toolchains published in the Go Module Mirror can be reproduced from source code, making it difficult to hide backdoors in the binaries downloaded by the go command.
A telemetry config tracker that tracks the names of telemetry counters uploaded by the Go toolchain, to ensure that Go telemetry is not violating users privacy.
As the homepage of the service mentions, the trackers are free software and do not rely on Google infrastructure.
In March 2024, a sophisticated backdoor was discovered in xz, a core compression library in Linux distributions, covertly inserted over three years by a malicious maintainer, Jia Tan. The attack, which enabled remote code execution via ssh, was only uncovered by chance when Andres Freund investigated a minor performance issue. This incident highlights the vulnerability of the open-source supply chain and the effort attackers are willing to invest in gaining trust and access. In this article, I analyze the backdoor s mechanics and explore how bitwise build reproducibility could have helped detect it.
Although quantum computing is a rapidly evolving field of research, it can already benefit from adopting reproducible builds. This paper aims to bridge the gap between the quantum computing and reproducible builds communities. We propose a generalization of the definition of reproducible builds in the quantum setting, motivated by two threat models: one targeting the confidentiality of end users data during circuit preparation and submission to a quantum computer, and another compromising the integrity of quantum computation results. This work presents three examples that show how classical information can be hidden in transpiled quantum circuits, and two cases illustrating how even minimal modifications to these circuits can lead to incorrect quantum computation results.
The thesis focuses on providing a reproducible build process for two open-source E2EE messaging applications: Signal and Wire. The motivation to ensure reproducibility and thereby the integrity of E2EE messaging applications stems from their central role as essential tools for modern digital privacy. These applications provide confidentiality for private and sensitive communications, and their compromise could undermine encryption mechanisms, potentially leaking sensitive data to third parties.
Currently, there are numerous solutions and techniques available in the market to tackle supply chain security, and all claim to be the best solution. This thesis delves deeper by implementing those solutions and evaluates them for better understanding. Some of the tools that this thesis implemented are Syft, Trivy, Grype, FOSSA, dependency-check, and Gemnasium. Software dependencies are generated in a Software Bill of Materials (SBOM) format by using these open-source tools, and the corresponding results have been analyzed. Among these tools, Syft and Trivy outperform others as they provide relevant and accurate information on software dependencies.
In the wake of growing supply chain attacks, the FreeBSD developers are relying on a transparent build concept in the form of Zero-Trust Builds. The approach builds on the established Reproducible Builds, where binary files can be rebuilt bit-for-bit from the published source code. While reproducible builds primarily ensure verifiability, the zero-trust model goes a step further and removes trust from the build process itself. No single server, maintainer, or compiler can be considered more than potentially trustworthy.
Upstream patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:
Bernhard Wiedemann and Zbigniew J drzejewski-Szmek extended ismypackagereproducibleyet.org with initial support for Fedora [].
In addition, a number of contributors added a series of notes from our recent summit to the website, including Alexander Couzens [], Robin Candau [][][][][][][][][] and kpcyrd [].
Tool development
diffoscope version 307 was uploaded to Debian unstable by Chris Lamb, who made a number of changes including fixing compatibility with LLVM version 21 [], an attempt to automatically attempt to deploy to PyPI by liaising with the PyPI developers/maintainers (with this experimental feature). [] In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 307.
Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
Another (again somewhat minor) maintenance release of the RcppCNPy
package arrived on CRAN just
now. RcppCNPy
provides R with read and write access to NumPy files thanks to the cnpy library by Carl Rogers
along with Rcpp for the glue to R.
The changes are all minor chores. As R now checks usage of packages
in demos, we added the rbenchmark to
Suggests: in DESCRIPTION. We refreshed the main continuous
integration script for a minor update, and also replaced one URL in a
badge to avoid a timeout during checks at CRAN. So nothing user-facing
this time! Full details are below.
Changes in version 0.2.14
(2024-11-03)
The rbenchmark package is now a
Suggests: as it appears in demo
The continuous integration setup now uses r-ci with
its embedded setup step
The URL used for the GPL-2 is now the R Project copy
This was the first year I attended Kernel
Recipes and I have nothing but say how
much I enjoyed it and how grateful I m for the opportunity to talk more about
kworkflow to very experienced kernel developers. What
I mostly like about Kernel Recipes is its intimate format, with only one track
and many moments to get closer to experts and people that you commonly talk
online during your whole year.
In the beginning of this year, I gave the talk Don t let your motivation go,
save time with kworkflow at
FOSDEM,
introducing kworkflow to a more diversified audience, with different levels of
involvement in the Linux kernel development.
At this year s Kernel Recipes I presented
the second talk of the first day: Kworkflow - mix & match kernel recipes end-to-end.
The Kernel Recipes audience is a bit different from FOSDEM, with mostly
long-term kernel developers, so I decided to just go directly to the point. I
showed kworkflow being part of the daily life of a typical kernel developer
from the local setup to install a custom kernel in different target machines to
the point of sending and applying patches to/from the mailing list. In short, I
showed how to mix and match kernel workflow recipes end-to-end.
As I was a bit fast when showing some features during my presentation, in this
blog post I explain each slide from my speaker notes. You can see a summary of
this presentation in the Kernel Recipe Live Blog Day 1: morning.
Introduction
Hi, I m Melissa Wen from Igalia. As we already started sharing kernel recipes
and even more is coming in the next three days, in this presentation I ll talk
about kworkflow: a cookbook to mix & match kernel recipes end-to-end.
This is my first time attending Kernel Recipes, so lemme introduce myself
briefly.
As I said, I work for Igalia, I work mostly on kernel GPU drivers in the DRM
subsystem.
In the past, I co-maintained VKMS and the v3d driver. Nowadays I focus on the
AMD display driver, mostly for the Steam Deck.
Besides code, I contribute to the Linux kernel by mentoring several newcomers
in Outreachy, Google Summer of Code and Igalia Coding Experience. Also, by
documenting and tooling the kernel.
And what s this cookbook called kworkflow?
Kworkflow (kw)
Kworkflow is a tool created by Rodrigo Siqueira, my colleague at Igalia. It s a
single platform that combines software and tools to:
optimize your kernel development workflow;
reduce time spent in repetitive tasks;
standardize best practices;
ensure that deployment data flows smoothly and reliably between different
kernel workflows;
It s mostly done by volunteers, kernel developers using their spare time. Its
features cover real use cases according to kernel developer needs.
Basically it s mixing and matching the daily life of a typical kernel developer
with kernel workflow recipes with some secret sauces.
First recipe: A good GPU driver for my AMD laptop
So, it s time to start the first recipe: A good GPU driver for my AMD laptop.
Before starting any recipe we need to check the necessary ingredients and
tools. So, let s check what you have at home.
With kworkflow, you can use:
kw device: to get information about the target machine, such as: CPU model,
kernel version, distribution, GPU model,
kw remote: to set the address of this machine for remote access
kw config: you can configure kw with kw config. With this command you can
basically select the tools, flags and preferences that kw will use to build
and deploy a custom kernel in a target machine. You can also define recipients
of your patches when sending it using kw send-patch. I ll explain more about
each feature later in this presentation.
kw kernel-config manager (or just kw k): to fetch the kernel .config file
from a given machine, store multiple .config files, list and retrieve them
according to your needs.
Now, with all ingredients and tools selected and well portioned, follow the
right steps to prepare your custom kernel!
First step: Mix ingredients with kw build or just kw b
kw b and its options wrap many routines of compiling a custom kernel.
You can run kw b -i to check the name and kernel version and the number
of modules that will be compiled and kw b --menu to change kernel
configurations.
You can also pre-configure compiling preferences in kw config regarding
kernel building. For example, target architecture, the name of the
generated kernel image, if you need to cross-compile this kernel for a
different system and which tool to use for it, setting different warning
levels, compiling with CFlags, etc.
Then you can just run kw b to compile the custom kernel for a target
machine.
Second step: Bake it with kw deploy or just kw d
After compiling the custom kernel, we want to install it in the target machine.
Check the name of the custom kernel built: 6.17.0-rc6 and with kw s SSH
access the target machine and see it s running the kernel from the Debian
distribution 6.16.7+deb14-amd64.
As with building settings, you can also pre-configure some deployment settings,
such as compression type, path to device tree binaries, target machine (remote,
local, vm), if you want to reboot the target machine just after deploying your
custom kernel, and if you want to boot in the custom kernel when restarting the
system after deployment.
If you didn t pre-configured some options, you can still customize as a command
option, for example: kw d --reboot will reboot the system after deployment,
even if I didn t set this in my preference.
With just running kw d --reboot I have installed the kernel in a given target
machine and rebooted it. So when accessing the system again I can see it was
booted in my custom kernel.
Third step: Time to taste with kw debug
kw debug wraps many tools for validating a kernel in a target machine. We
can log basic dmesg info but also tracking events and ftrace.
With kw debug --dmesg --history we can grab the full dmesg log from a
remote machine, if you use the --follow option, you will monitor dmesg
outputs. You can also run a command with kw debug --dmesg --cmd="<my
command>" and just collect the dmesg output related to this specific execution
period.
In the example, I ll just unload the amdgpu driver. I use kw drm
--gui-off to drop the graphical interface and release the amdgpu for
unloading it. So I run kw debug --dmesg --cmd="modprobe -r amdgpu" to unload
the amdgpu driver, but it fails and I couldn t unload it.
Cooking Problems
Oh no! That custom kernel isn t tasting good. Don t worry, as in many recipes
preparations, we can search on the internet to find suggestions on how to make
it tasteful, alternative ingredients and other flavours according to your
taste.
With kw patch-hub you can search on the lore kernel mailing list for possible
patches that can fix your kernel issue. You can navigate in the mailing lists,
check series, bookmark it if you find it relevant and apply it in your local
kernel tree, creating a different branch for tasting oops, for testing. In
this example, I m opening the amd-gfx mailing list where I can find
contributions related to the AMD GPU driver, bookmark and/or just apply the
series to my work tree and with kw bd I can compile & install the custom kernel
with this possible bug fix in one shot.
As I changed my kw config to reboot after deployment, I just need to wait for
the system to boot to try again unloading the amdgpu driver with kw debug
--dmesg --cm=modprobe -r amdgpu. From the dmesg output retrieved by kw for
this command, the driver was unloaded, the problem is fixed by this series and
the kernel tastes good now.
If I m satisfied with the solution, I can even use kw patch-hub to access the
bookmarked series and marking the checkbox that will reply the patch thread
with a Reviewed-by tag for me.
Second Recipe: Raspberry Pi 4 with Upstream Kernel
As in all recipes, we need ingredients and tools, but with kworkflow you can
get everything set as when changing scenarios in a TV show. We can use kw env
to change to a different environment with all kw and kernel configuration set
and also with the latest compiled kernel cached.
I was preparing the first recipe for a x86 AMD laptop and with kw env --use
RPI_64 I use the same worktree but moved to a different kernel workflow, now
for Raspberry Pi 4 64 bits. The previous compiled kernel 6.17.0-rc6-mainline+
is there with 1266 modules, not the 6.17.0-rc6 kernel with 285 modules that I
just built&deployed. kw build settings are also different, now I m targeting
a arm64 architecture with a cross-compiled kernel using aarch64-linu-gnu-
cross-compilation tool and my kernel image calls kernel8 now.
If you didn t plan for this recipe in advance, don t worry. You can create a
new environment with kw env --create RPI_64_V2 and run kw init --template
to start preparing your kernel recipe with the mirepoix ready.
I mean, with the basic ingredients already cut
I mean, with the kw configuration set from a template.
And you can use kw remote to set the IP address of your target machine and
kw kernel-config-manager to fetch/retrieve the .config file from your target
machine. So just run kw bd to compile and install a upstream kernel for
Raspberry Pi 4.
Third Recipe: The Mainline Kernel Ringing on my Steam Deck (Live Demo)
Let s show you how easy is to build, install and test a custom kernel for Steam
Deck with Kworkflow. It s a live demo, but I also recorded it because I know
the risks I m exposed to and something can go very wrong just because of
reasons :)
Report: how was the live demo
For this live demo, I took my OLED Steam Deck to the stage. I explained that,
if I boot mainline kernel on this device, there is no audio. So I turned it on
and booted the mainline kernel I ve installed beforehand. It was clear that
there was no typical Steam Deck startup audio when the system was loaded.
As I started the demo in the kw environment for Raspberry Pi 4, I first moved
to another environment previously used for Steam Deck. In this STEAMDECK
environment, the mainline kernel was already compiled and cached, and all
settings for accessing the target machine, compiling and installing a custom
kernel were retrieved automatically.
My live demo followed these steps:
With kw env --use STEAMDECK, switch to a kworkflow environment for Steam
Deck kernel development.
With kw b -i, shows that kw will compile and install a kernel with 285
modules named 6.17.0-rc6-mainline-for-deck.
Run kw config to show that, in this environment, kw configuration changes
to x86 architecture and without cross-compilation.
Run kw device to display information about the Steam Deck device, i.e. the
target machine. It also proves that the remote access - user and IP - for
this Steam Deck was already configured when using the STEAMDECK environment, as
expected.
Using git am, as usual, apply a hot fix on top of the mainline kernel.
This hot fix makes the audio play again on Steam Deck.
With kw b, build the kernel with the audio change. It will be fast because
we are only compiling the affected files since everything was previously
done and cached. Compiled kernel, kw configuration and kernel configuration is
retrieved by just moving to the STEAMDECK environment.
Run kw d --force --reboot to deploy the new custom kernel to the target
machine. The --force option enables us to install the mainline kernel even
if mkinitcpio complains about missing support for downstream packages when
generating initramfs. The --reboot option makes the device reboot the Steam
Deck automatically, just after the deployment completion.
After finishing deployment, the Steam Deck will reboot on the new custom
kernel version and made a clear resonant or vibrating sound. [Hopefully]
Finally, I showed to the audience that, if I wanted to send this patch
upstream, I just needed to run kw send-patch and kw would automatically add
subsystem maintainers, reviewers and mailing lists for the affected files as
recipients, and send the patch to the upstream community assessment. As I
didn t want to create unnecessary noise, I just did a dry-run with kw
send-patch -s --simulate to explain how it looks.
What else can kworkflow already mix & match?
In this presentation, I showed that kworkflow supported different kernel
development workflows, i.e., multiple distributions, different bootloaders and
architectures, different target machines, different debugging tools and
automatize your kernel development routines best practices, from development
environment setup and verifying a custom kernel in bare-metal to sending
contributions upstream following the contributions-by-e-mail structure. I
exemplified it with three different target machines: my ordinary x86 AMD laptop
with Debian, Raspberry Pi 4 with arm64 Raspbian (cross-compilation) and the
Steam Deck with SteamOS (x86 Arch-based OS). Besides those distributions,
Kworkflow also supports Ubuntu, Fedora and PopOS.
Now it s your turn: Do you have any secret recipes to share? Please share
with us via kworkflow.
Introduction
For personal web site, I use hugo and hugo-theme-learn for statically generated contents.
Recently I've noticed that these combination of specific version is not compatible with.
(Not so frequently update contents, so it was delayed to found this situation)
What was the actual error?
ERROR deprecated: .Site.IsMultiLingual was deprecated in Hugo v0.124.0 and subsequently removed. Use hugo.IsMultilingual instead.
Total in 21 ms
It seems that hugo-theme-learn is not compatible with recent Hugo anymore.
How to deal with it?
With checking upstream issue, I've found the following issue.
What are people migrating too?
'hugo-theme-relearn' was noted as an alternative.
As 'hugo-theme-learn' is not actively maintained anymore, so it is easy to migrate from hugo-theme-learn to hugo-theme-relearn.
For example, it needs just a few lines of configuration.
It was sad that hugo-theme-learn is not maintained actively, but many thank to this greateful hugo theme.
And also thanks the effort to fork it as hugo-theme-relearn.
Quiete some things made progress last month: We put out
Phosh 0.50 release, got
closer to enabling media roles for audio by default in Phosh (see related
post) and reworked
our images builds. You should also (hopefully) notice some nice
quality of life improvements once changes land in a distro near you
and you're using Phosh. See below for details:
phosh
Switch back to default them when disabling automatic HighContrast (MR)
Hande gnome-session 49 changes so OSK can still start up (MR)
I am a huge fan of Git, as I have witnessed how it has made software development so much more productive compared to the pre-2010s era. I wish all Debian source code were in Git to reap the full benefits.
Git is not perfect, as it requires significant effort to learn properly, and the ecosystem is complex with even more things to learn ranging from cryptographic signatures and commit hooks to Git-assisted code review best practices, forge websites, and CI systems.
Sure, there is still room to optimize its use, but Git certainly has proven itself and is now the industry standard. Thus, some readers might be surprised to learn that Debian development in 2025 is not actually based on Git. In Debian, the version control is done by the Debian archive itself. Each commit is a new upload to the archive, and the commit message is the 
The Debian LTS Team, funded by 
Welcome to post 55 in the 
After cartridge pleating and honeycombing, I was still somewhat in the
mood for that kind of fabric manipulation, and directing my internet
searches in that vague direction, and I stumbled on this:
With the pieces being rectangles the width of the fabric, I was able to
have at least one side of selvedge on all seams, and took advantage of it
by finishing the seams by simply folding the allowances to one sides so
that the selvedge was on top, and hemstitching them down as I would have
done with a folded edge when felling.
Also, at first I wanted to make the smocking in white on white, but then
I thought about a few hanks of electric blue floss I had in my stash,
and decided to just go with it.
The initial seams were quickly made, then I started the smocking at the
neck, and at that time the project went on hold while I got ready to go
to DebConf. Then I came back and took some time to get back into a
sewing mood, but finally the smocking on the next was finished, and I
could go on with the main sewing, which, as I expected, went decently
fast for a handsewing project.
While doing the diagonal smocking on the collar I counted the stitches
to make each side the same length, which didn t completely work because
the gathers weren t that regular to start with, and started each line
from the two front opening going towards the center back, leaving a
triangle with a different size right in the middle. I think overall it
worked well enough.
Then there were a few more interruptions, but at last it was ready! just
as the weather turned cold-ish and puffy shirts were no longer in
season, but it will be there for me next spring.
I did manage to wear it a few times and I have to say that the neck
shaping is quite comfortable indeed: it doesn t pull in odd ways like
the classical historically accurate pirate shirt sometimes does, and the
heavy gathering at the neck makes it feel padded and soft.
I m not as happy with the cuffs: the way I did them with just
honeycombing means that they don t need a closure, and after washing and
a bit of steaming they lie nicely, but then they tend to relax in a
wider shape. The next time I think I ll leave a slit in the sleeves,
possibly make a different type of smocking (depending on whether I have
enough fabric) and then line them like the neck so that they are stable.
Because, yes, I think that there will be another time: I have a few more
project before that, and I want to spend maybe another year working from
my stash, but then I think I ll buy some soft linen and make at least
another one, maybe with white-on-white smocking so that it will be
easier to match with different garments.
About 95% of my Debian contributions this month were
This was the first year I attended 
Hi, I m Melissa Wen from Igalia. As we already started sharing kernel recipes
and even more is coming in the next three days, in this presentation I ll talk
about kworkflow: a cookbook to mix & match kernel recipes end-to-end.
This is my first time attending Kernel Recipes, so lemme introduce myself
briefly.
And what s this cookbook called kworkflow?
Kworkflow is a tool created by 
It s mostly done by volunteers, kernel developers using their spare time. Its
features cover real use cases according to kernel developer needs.
Basically it s mixing and matching the daily life of a typical kernel developer
with kernel workflow recipes with some secret sauces.
So, it s time to start the first recipe: A good GPU driver for my AMD laptop.
Before starting any recipe we need to check the necessary ingredients and
tools. So, let s check what you have at home.
With kworkflow, you can use:
Now, with all ingredients and tools selected and well portioned, follow the
right steps to prepare your custom kernel!
First step: Mix ingredients with 
After compiling the custom kernel, we want to install it in the target machine.
Check the name of the custom kernel built: 
Oh no! That custom kernel isn t tasting good. Don t worry, as in many recipes
preparations, we can search on the internet to find suggestions on how to make
it tasteful, alternative ingredients and other flavours according to your
taste.
With 
As in all recipes, we need ingredients and tools, but with kworkflow you can
get everything set as when changing scenarios in a TV show. We can use kw env
to change to a different environment with all kw and kernel configuration set
and also with the latest compiled kernel cached.
I was preparing the first recipe for a x86 AMD laptop and with 
If you didn t plan for this recipe in advance, don t worry. You can create a
new environment with 
And you can use 
Let s show you how easy is to build, install and test a custom kernel for Steam
Deck with Kworkflow. It s a live demo, but I also recorded it because I know
the risks I m exposed to and something can go very wrong just because of
reasons :)
As I started the demo in the kw environment for Raspberry Pi 4, I first moved
to another environment previously used for Steam Deck. In this STEAMDECK
environment, the mainline kernel was already compiled and cached, and all
settings for accessing the target machine, compiling and installing a custom
kernel were retrieved automatically.
My live demo followed these steps:
Quiete some things made progress last month: We put out