Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 1 hour 18 min ago

Enrico Zini: nspawn-runner: support for image selection

25 January, 2021 - 22:49

.gitlab-ci.yml supports 'image' to allow selecting in which environment the script gets run. The documentation says "Used to specify a Docker image to use for the job", but it's clearly a bug in the documentation, because we can do it with nspawn-runner, too.

It turns out that most of the environment variables available to CI runs are also available to custom runner scripts. In this case, the value passed as image can be found as $CUSTOM_ENV_CI_JOB_IMAGE in the custom runner scripts environment.

After some experimentation I made this commit that makes every chroot under /var/lib/nspawn-runner available as an image:

# Set up 3 new images for CI jobs:
nspawn-runner chroot-create buster
nspawn-runner chroot-create bullseye
nspawn-runner chroot-create sid

That's it, CI scripts can now use image: buster, image: bullseye or image: sid, as they please. You can manually set up other chroots under /var/lib/nspawn-runner and they'll be automatically available.

You can also now choose a default image in config.toml in case the CI script doesn't specify one:

prepare_args = ["--verbose", "prepare", "--default-image=buster"]

Russ Allbery: Review: Laziness Does Not Exist

25 January, 2021 - 12:00

Review: Laziness Does Not Exist, by Devon Price

Publisher: Atria Books Copyright: January 2021 ISBN: 1-9821-4013-5 Format: Kindle Pages: 216

The premise of Laziness Does Not Exist is in the title: Laziness as a moral failing does not exist. It is a misunderstanding of other problems with physical or psychological causes, a belief system that is used to extract unsustainable amounts of labor, an excuse to withdraw our empathy, and a justification for not solving social problems. Price refers to this as the Laziness Lie, which they define with three main tenets:

  1. Your worth is your productivity.
  2. You cannot trust your own feelings and limits.
  3. There is always more you could be doing.

This book (an expansion of a Medium article) makes the case against all three tenets using the author's own burnout-caused health problems as the starting argument. They then apply that analysis to work, achievements, information overload, relationships, and social pressure. In each case, Price's argument is to prioritize comfort and relaxation, listen to your body and your limits, and learn who you are rather than who the Laziness Lie is trying to push you to be.

The reader reaction to a book like this will depend on where the reader is in thinking about the problem. That makes reviewing a challenge, since it's hard to simulate a reader with a different perspective. For myself, I found the content unobjectionable, but largely repetitive of other things I've read. The section on relationships in particular will be very familiar to Captain Awkward readers, just not as pointed. Similarly, the chapter on information overload is ground already covered by Digital Minimalism, among other books. That doesn't make this a bad book, but it's more of a survey, so if you're already well-read on this topic you may not get much out of it.

The core assertion is aggressive in part to get the reader to argue with it and thus pay attention, but I still came away convinced that laziness is not a useful word. The symptoms that cause us to call ourselves lazy — procrastination, burnout, depression, or executive function problems, for example — are better understood without the weight of moral reproach that laziness carries. I do think there is another meaning of laziness that Price doesn't cover, since they are aiming this book exclusively at people who are feeling guilty about possibly being lazy, and we need some term for people who use their social power to get other people to do all their work for them. But given how much the concept of laziness is used to attack and belittle the hard-working or exhausted, I'm happy to replace "laziness" with "exploitation" when talking about that behavior.

This is a profoundly kind and gentle book. Price's goal is to help people be less hard on themselves and to take opportunities to relax without guilt. But that also means that it stays in the frame of psychological analysis and self-help, and only rarely strays into political or economic commentary. That means it's more useful for taking apart internalized social programming, but less useful for thinking about the broader political motives of those who try to convince us to working endlessly and treat all problems as personal responsibilities rather than political failures. For that, I think Anne Helen Peterson's Can't Even is the more effective book. Price also doesn't delve much into history, and I now want to read a book on the origin of a work ethic as a defining moral trait.

One truly lovely thing about this book is that it's quietly comfortable with human variety of gender and sexuality in a way that's never belabored but that's obvious from the examples that Price uses. Laziness Does Not Exist felt more inclusive in that way, and to some extent on economic class, than Can't Even.

I was in the mood for a book that takes apart the political, social, and economic motivations behind convincing people that they have to constantly strive to not be lazy, so the survey nature of this book and its focus on self-help made it not the book for me. It also felt a bit repetitive despite its slim length, and the chapter structure didn't click for me. But it's not a bad book, and I suspect it will be the book that someone else needs to read.

Rating: 6 out of 10

Iustin Pop: Raspbian/Raspberry PI OS with initrd

25 January, 2021 - 08:33

While Raspbian, ahem, Raspberry PI OS is mostly Debian, the biggest difference is the kernel, both in terms of code and packaging.

The packaging is weird since it needs to deal with the fact that there’s no bootloader per se, the firmware parses /boot/config.txt and depending on the setting of 64bit and/or kernel line, it loads a specific file. Normally, one of kernel7.img, kernel7l.img or kernel8.img. While this configuration file supports an initrd, it doesn’t have a clean way to associate an initrd with a kernel, but rather you have to (like for the actual kernel) settle on a hard-coded initrd name.

Due to this, the normal way of using an initrd doesn’t work, and one has to do two things:

  • enable building initrd’s at all
  • settle on the naming for the initrd
  • ensure the initrd is updated correctly

There are quite a few of forum threads about this, but there’s no official support for this. The best link I found was this Stack Exchange post, which goes most of the way, but fails at the third point above.

My trivial solution

Instead of naming tricks the above post suggests, I settled on having a fixed name. It risks boot failure when the kernel architecture will change, which could be worked around with hard-coded kernel too, but I haven’t done that yet.

First, enable initrd creation/update in /etc/default/raspberrypi-kernel, like the post says. Uncomment INITRD=yes, but not the RPI_INITRD. This will enable creating/updating the initrd when the kernel package is installed and/or other packages trigger it via hooks.

Second, naming: choose an initrd name. I have simply this in my config.txt:

initramfs initrd.img followkernel

So the value is fully hard-coded, and the actual work is done in the next part.

Last, add an initramfs-hook in (e.g.) /etc/initramfs/post-update.d/rpi-initrd. Note that, by default (unless other packages have created it), the /etc/initramfs directory doesn’t exist. It’s not the confusingly-named /etc/initramfs-tools/ directory, which is related to building the initrd, but rather to doing things with the (already built) initrd. This directory is briefly explain in the Debian kernel-handbook guide.

This is my contents:


BOOTDIR="$(dirname "$INITRD")"

# Note: the match below _must_ be synced with the boot kernel
if [[ "$ABI" == *-v8+ ]]; then
        echo "Building v8l+ image, updating top initrd"
        cp -p "$INITRD" "$BOOTDIR/initrd.img"

This script seems to me much simpler, so in principle less chance of bugs, than all the renaming and editing config.txt I saw in that stack exchange post. As far as I know, all one needs to care about is to sync the ABI passed to this hook with the kernel one is running, and since there is only one kernel version installed at a time on Raspbian (as there’s no versioning in the kernel names), this should work correctly.

With this hook, the update also works correctly when packages trigger initrd updates, not only when new kernels are installed.

Note that the cp there is needed since the book partition is FAT, so no symbolic links/hard links allowed.

Happy initrd’ing!

Enrico Zini: Miscellaneous news links

25 January, 2021 - 06:00

Some curious news.

Here's a scam that targets terrorists: The Doomsday Scam.

On the general topic of scams, a List of confidence tricks.

Then two news involving bread:

And a last one about how people needed to rename human genes to work around Excel bugsfeatures:

Dirk Eddelbuettel: prrd 0.0.4: More tweaks

24 January, 2021 - 05:31

prrd facilitates the parallel running [of] reverse dependency [checks] when preparing R packages. It is used extensively for Rcpp, RcppArmadillo, RcppEigen, BH, and possibly others.

The key idea of prrd is simple, and described in some more detail on its webpage and its GitHub repo. Reverse dependency checks are an important part of package development that is easily done in a (serial) loop. But these checks are also generally embarassingly parallel as there is no or little interdependency between them (besides maybe shared build depedencies). See the (dated) screenshot (running six parallel workers, arranged in split byobu session).

This release brings several smaller tweaks and improvements to the summary report that had accumulated in my use since the last realease last April. We also updated the CI runners as one does these days.

The release is summarised in the NEWS entry:

Changes in prrd version 0.0.4 (2021-01-23)
  • Report summary mode is now compact, more robust and reports extended CRAN summaries. (Dirk via several changes)

  • Continuous Integration now uses from r-ci

My CRANberries provides the usual summary of changes to the previous version. See the aforementioned webpage and its repo for details. For more questions or comments use the issue tracker off the GitHub repo.

If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Sylvain Beucler: Android Emulator Rebuild

23 January, 2021 - 20:02

Android Rebuilds provides freely-licensed builds of Android development tools from a Mountain View-based company.

The Emulator package moved to a separate component and build system.

Emulator 30 is now available, as unattended Docker build scripts, build documentation as well as convenience binaries.

Louis-Philippe Véronneau: Montreal Subway Foot Traffic Data, Revisited

23 January, 2021 - 12:00

In 2019, I got curious and asked Société de Transport de Montréal, Montreal's transit agency, for the foot traffic data of Montreal's subway.

Since then, two years has passed and with COVID-19 still going strong, I wanted to see what impact the pandemic had had. And oh boy, what an impact it is.

So here it is, data from 2001 to 2020, graphed the same way as in the original 2019 blog post. I could certainly juice this data, graph the pandemic using daily figures and come up with a long and interesting blog post analysing the main trends. I start teaching next Monday though and I still have prep work to do, so I'll leave that to someone else.

By clicking on a subway station, you'll be redirected to a graph of the station's foot traffic.

  • The subway map displayed on this page, the original dataset and my modified dataset are licenced under CCO 1.0: they are in the public domain.

  • The R code I wrote is licensed under the GPLv3+. Feel free to reuse it and write something nice about how the pandemic impacted the STM. I've made small changes to the 2019 version, but it's mostly the same thing.

Reproducible Builds (diffoscope): diffoscope 165 released

23 January, 2021 - 07:00

The diffoscope maintainers are pleased to announce the release of diffoscope version 165. This version includes the following changes:

[ Dimitrios Apostolou ]
* Introduce the --no-acl and --no-xattr arguments [later collapsed to
  --extended-filesystem-attributes] to improve performance.
* Avoid calling the external stat command.

[ Chris Lamb ]
* Collapse --acl and --xattr into --extended-filesystem-attributes to cover
  all of these extended attributes, defaulting the new option to false (ie.
  to not check these very expensive external calls).

[ Mattia Rizzolo ]
* Override several lintian warnings regarding prebuilt binaries in the
* source.
* Add a pytest.ini file to explicitly use Junit's xunit2 format.
* Ignore the Python DeprecationWarning message regarding the `imp` module
  deprecation as it comes from a third-party library.
* debian/rules: filter the content of the d/*.substvars files

You find out more by visiting the project homepage.

Robert McQueen: Launching Endless OS Foundation

23 January, 2021 - 00:00
How our for-profit company became a nonprofit, to better tackle the digital divide.

Originally posted on the Endless OS Foundation blog.

An 8-year journey to a nonprofit

On the 1st of April 2020, our for-profit Endless Mobile officially became a nonprofit as the Endless OS Foundation. Our launch as a nonprofit just as the global pandemic took hold was, predictably, hardly noticed, but for us the timing was incredible: as the world collectively asked “What can we do to help others in need?”, we framed our mission statement and launched our .org with the same very important question in mind. Endless always had a social impact mission at its heart, and the challenges related to students, families, and communities falling further into the digital divide during COVID-19 brought new urgency and purpose to our team’s decision to officially step in the social welfare space.

On April 1st 2020, our for-profit Endless Mobile officially became a nonprofit as the Endless OS Foundation, focused on the #DigitalDivide.

Our updated status was a long time coming: we began our transformation to a nonprofit organization in late 2019 with the realization that the true charter and passions of our team would be greatly accelerated without the constraints of for-profit goals, investors and sales strategies standing in the way of our mission of digital access and equity for all. 

But for 8 years we made a go of it commercially, headquartered in Silicon Valley and framing ourselves as a tech startup with access to the venture capital and partnerships on our doorstep. We believed that a successful commercial channel would be the most efficient way to scale the impact of bringing computer devices and access to communities in need. We still believe this – we’ve just learned through our experience that we don’t have the funding to enter the computer and OS marketplace head-on. With the social impact goal first, and the hope of any revenue a secondary goal, we have had many successes in those 8 years bridging the digital divide throughout the world, from Brazil, to Kenya, and the USA. We’ve learned a huge amount which will go on to inform our strategy as a nonprofit.

Endless always had a social impact mission at its heart. COVID-19 brought new urgency and purpose to our team’s decision to officially step in the social welfare space.

Our unique perspective

One thing we learned as a for-profit is that the OS and technology we’ve built has some unique properties which are hugely impactful as a working solution to digital equity barriers. And our experience deploying in the field around the world for 8 years has left us uniquely informed via many iterations and incremental improvements.

With this knowledge in-hand, we’ve been refining our strategy throughout 2020 and now starting to focus on what it really means to become an effective nonprofit and make that impact. In many ways it is liberating to abandon the goals and constraints of being a for-profit entity, and in other ways it’s been a challenging journey for me and the team to adjust our way of thinking and let these for-profit notions and models go. Previously we exclusively built and sold a product that defined our success; and any impact we achieved was a secondary consequence of that success and seen through that lens. Now our success is defined purely in terms of social impact, and through our actions, those positive impacts can be made with or without our “product”. That means that we may develop and introduce technology to solve a problem, but it is equally as valid to find another organization’s existing offering and design a way to increase that positive impact and scale.

We develop technology to solve access equity issues, but it’s equally as valid to find another organization’s offering and partner in a way that increases their positive impact.

The analogy to Free and Open Source Software is very strong – while Endless has always used and contributed to a wide variety of FOSS projects, we’ve also had a tension where we’ve been trying to hold some pieces back and capture value – such as our own application or content ecosystem, our own hardware platform – necessarily making us competitors to other organisations even though they were hoping to achieve the same things as us. As a nonprofit we can let these ideas go and just pick the best partners and technologies to help the people we’re trying to reach.

Digital equity … 4 barriers we need to overcome

In future, our decisions around which projects to build or engage with will revolve around 4 barriers to digital equity, and how our Endless OS, Endless projects, or our partners’ offerings can help to solve them. We define these 4 equity barriers as: barriers to devices, barriers to connectivity, barriers to literacy in terms of your ability to use the technology, and barriers to engagement in terms of whether using the system is rewarding and worthwhile.

We define the 4 digital equity barriers we exist to impact as:
1. barriers to devices
2. barriers to connectivity
3. barriers to literacy
4. barriers to engagement

It doesn’t matter who makes the solutions that break these barriers; what matters is how we assist in enabling people to use technology to gain access to the education and opportunities these barriers block. Our goal therefore is to simply ensure that solutions exist – building them ourselves and with partners such as the FOSS community and other nonprofits – proving them with real-world deployments, and sharing our results as widely as possible to allow for better adoption globally.

If we define our goal purely in terms of whether people are using Endless OS, we are effectively restricting the reach and scale of our solutions to the audience we can reach directly with Endless OS downloads, installs and propagation. Conversely, partnerships that scale impact are a win-win-win for us, our partners, and the communities we all serve. 

Engineering impact

Our Endless engineering roots and capabilities feed our unique ability to build and deploy all of our solutions, and the practical experience of deploying them gives us evidence and credibility as we advocate for their use. Either activity would be weaker without the other.

Our engineering roots and capabilities feed our unique ability to build and deploy digital divide solutions.

Our partners in various engineering communities will have already seen our change in approach. Particularly, with GNOME we are working hard to invest in upstream and reconcile the long-standing differences between our experience and GNOME. If successful, many more people can benefit from our work than just users of Endless OS. We’re working with Learning Equality on Kolibri to build a better app experience for Linux desktop users and bring content publishers into our ecosystem for the first time, and we’ve also taken our very own Hack, the immersive and fun destination for kids learning to code, released it for non-Endless systems on Flathub, and made it fully open-source.

What’s next for our OS?

What then is in store for the future of Endless OS, the place where we have invested so much time and planning through years of iterations? For the immediate future, we need the capacity to deploy everything we’ve built – all at once, to our partners. We built an OS that we feel is very unique and valuable, containing a number of world-firsts: first production OS shipped with OSTree, first Flatpak-only desktop, built-in support for updating OS and apps from USBs, while still providing a great deal of reliability and convenience for deployments in offline and educational-safe environments with great apps and content loaded on every system.

However, we need to find a way to deliver this Linux-based experience in a more efficient way, and we’d love to talk if you have ideas about how we can do this, perhaps as partners. Can the idea of “Endless OS” evolve to become a spec that is provided by different platforms in the future, maybe remixes of Debian, Fedora, openSUSE or Ubuntu? 

Build, Validate, Advocate

Beyond the OS, the Endless OS Foundation has identified multiple programs to help underserved communities, and in each case we are adopting our “build, validate, advocate” strategy. This approach underpins all of our projects: can we build the technology (or assist in the making), will a community in-need validate it by adoption, and can we inspire others by telling the story and advocating for its wider use?

We are adopting a “build, validate, advocate” strategy.
1. build the technology (or assist in the making)
2. validate by community adoption
3. advocate for its wider use

As examples, we have just launched the Endless Key (link) as an offline solution for students during the COVID-19 at-home distance learning challenges. This project is also establishing a first-ever partnership of well-known online educational brands to reach an underserved offline audience with valuable learning resources. We are developing a pay-as-you-go platform and new partnerships that will allow families to own laptops via micro-payments that are built directly into the operating system, even if they cannot qualify for standard retail financing. And during the pandemic, we’ve partnered with Teach For America to focus on very practical digital equity needs in the USA’s urban and rural communities.

One part of the world-wide digital divide solution

We are one solution provider for the complex matrix of issues known collectively as the #DigitalDivide, and these issues will not disappear after the pandemic. Digital equity was an issue long before COVID-19, and we are not so naive to think it can be solved by any single institution, or by the time the pandemic recedes. It will take time and a coalition of partnerships to win. We are in for the long-haul and we are always looking for partners, especially now as we are finding our feet in the nonprofit world. We’d love to hear from you, so please feel free to reach out to me on RocketChat, Twitter, LinkedIn or

Bits from Debian: New Debian Maintainers (November and December 2020)

23 January, 2021 - 00:00

The following contributors were added as Debian Maintainers in the last two months:

  • Timo Röhling
  • Fabio Augusto De Muzio Tobich
  • Arun Kumar Pariyar
  • Francis Murtagh
  • William Desportes
  • Robin Gustafsson
  • Nicholas Guriev


Enrico Zini: Polishing nspawn-runner

22 January, 2021 - 23:50

This post is part of a series about trying to setup a gitlab runner based on systemd-nspawn. I published the polished result as nspawn-runner on GitHub.

gitlab-runner supports adding extra arguments to the custom scripts, and I can take advantage of that to pack all the various scripts that I prototyped so far into an all-in-one nspawn-runner command:

usage: nspawn-runner [-h] [-v] [--debug]

Manage systemd-nspawn machines for CI runs.

positional arguments:
                        sub-command help
    chroot-create       create a chroot that serves as a base for ephemeral
    chroot-login        enter the chroot to perform maintenance
    prepare             start an ephemeral system for a CI run
    run                 run a command inside a CI machine
    cleanup             cleanup a CI machine after it's run
    gitlab-config       configuration step for gitlab-runner
    toml                output the toml configuration for the custom runner

optional arguments:
  -h, --help            show this help message and exit
  -v, --verbose         verbose output
  --debug               verbose output
chroot maintenance

chroot-create and chroot-login are similar to what pbuilder, cowbuilder, schroot, debspawn and similar tools do.

They only take a chroot name, and default the rest of paths to where nspawn-runner expects things to be under /var/lib/nspawn-runner.

gitlab-runner setup

nspawn-runner toml <chroot-name> outputs a snippet to add to /etc/gitlab-runner/config.toml to configure the CI.

For example:`

$ ./nspawn-runner toml buster
  executor = "custom"
  builds_dir = "/var/lib/nspawn-runner/.build"
  cache_dir = "/var/lib/nspawn-runner/.cache"
    config_exec = "/home/enrico/…/nspawn-runner/nspawn-runner"
    config_args = ["gitlab-config"]
    config_exec_timeout = 200
    prepare_exec = "/home/enrico/…/nspawn-runner/nspawn-runner"
    prepare_args = ["prepare", "buster"]
    prepare_exec_timeout = 200
    run_exec = "/home/enrico/dev/nspawn-runner/nspawn-runner"
    run_args = ["run"]
    cleanup_exec = "/home/enrico/…/nspawn-runner/nspawn-runner"
    cleanup_args = ["cleanup"]
    cleanup_exec_timeout = 200
    graceful_kill_timeout = 200
    force_kill_timeout = 200

One needs to remember to set url and token, and the runner is configured.

The end, for now

This is it, it works! Time will tell what issues or ideas will come up: for now, it's a pretty decent first version.

The various prepare, run, cleanup steps are generic enough that they can be used outside of gitlab-runner: feel free to build on them, and drop me a note if you find this useful!

Enrico Zini: Assembling the custom runner

22 January, 2021 - 23:40

This post is part of a series about trying to setup a gitlab runner based on systemd-nspawn. I published the polished result as nspawn-runner on GitHub.

The plan

Back to custom runners, here's my plan:

  • config can be a noop
  • prepare starts the nspawn machine
  • run runs scripts with machinectl shell
  • cleanup runs machinectl stop
The scripts

Here are the scripts based on Federico's work: with definitions sourced by all scripts:

OVERLAY="/var/lib/gitlab-runner-custom-chroots/$MACHINE" doing nothing:

exit 0 starting the machine:


source $(dirname "$0")/
set -eo pipefail

# trap errors as a CI system failure

logger "gitlab CI: preparing $MACHINE"

mkdir -p $OVERLAY

systemd-run \
  -p 'KillMode=mixed' \
  -p 'Type=notify' \
  -p 'RestartForceExitStatus=133' \
  -p 'SuccessExitStatus=133' \
  -p 'Slice=machine.slice' \
  -p 'Delegate=yes' \
  -p 'TasksMax=16384' \
  -p 'WatchdogSec=3min' \
  systemd-nspawn --quiet -D $ROOTFS \
    --machine="$MACHINE" --boot --notify-ready=yes running the provided scripts in the machine:

logger "gitlab CI: running $@"
source $(dirname "$0")/

set -eo pipefail

systemd-run --quiet --pipe --wait --machine="$MACHINE" /bin/bash < "$1" stopping the machine and removing the writable overlay directory:

logger "gitlab CI: cleanup $@"
source $(dirname "$0")/

machinectl stop "$MACHINE"
rm -rf $OVERLAY
Trying out the plan

I tried a manual invocation of gitlab-runner, and it worked perfectly:

# mkdir /var/lib/gitlab-runner-custom-chroots/build/
# mkdir /var/lib/gitlab-runner-custom-chroots/cache/
# gitlab-runner exec custom \
    --builds-dir /var/lib/gitlab-runner-custom-chroots/build/ \
    --cache-dir /var/lib/gitlab-runner-custom-chroots/cache/ \
    --custom-config-exec /var/lib/gitlab-runner-custom-chroots/ \
    --custom-prepare-exec /var/lib/gitlab-runner-custom-chroots/ \
    --custom-run-exec /var/lib/gitlab-runner-custom-chroots/ \
    --custom-cleanup-exec /var/lib/gitlab-runner-custom-chroots/ \
Runtime platform                                    arch=amd64 os=linux pid=18662 revision=775dd39d version=13.8.0
Running with gitlab-runner 13.8.0 (775dd39d)
Preparing the "custom" executor
Using Custom executor...
Running as unit: run-r1be98e274224456184cbdefc0690bc71.service
executor not supported                              job=1 project=0 referee=metrics
Preparing environment

Getting source from Git repository

Executing "step_script" stage of the job script
WARNING: Starting with version 14.0 the 'build_script' stage will be replaced with 'step_script':

Job succeeded

The remaining step is to deploy all this in /etc/gitlab-runner/config.toml:

concurrent = 1
check_interval = 0

  session_timeout = 1800

  name = "nspawn runner"
  url = "http://gitlab.siweb.local/"
  token = "…"
  executor = "custom"
  builds_dir = "/var/lib/gitlab-runner-custom-chroots/build/"
  cache_dir = "/var/lib/gitlab-runner-custom-chroots/cache/"
    config_exec = "/var/lib/gitlab-runner-custom-chroots/"
    config_exec_timeout = 200
    prepare_exec = "/var/lib/gitlab-runner-custom-chroots/"
    prepare_exec_timeout = 200
    run_exec = "/var/lib/gitlab-runner-custom-chroots/"
    cleanup_exec = "/var/lib/gitlab-runner-custom-chroots/"
    cleanup_exec_timeout = 200
    graceful_kill_timeout = 200
    force_kill_timeout = 200
Next steps

My next step will be polishing all this in a way that makes deploying and maintaining a runner configuration easy.

Enrico Zini: Exploring nspawn for CIs

22 January, 2021 - 23:30

This post is part of a series about trying to setup a gitlab runner based on systemd-nspawn. I published the polished result as nspawn-runner on GitHub.

Here I try to figure out possible ways of invoking nspawn for the prepare, run, and cleanup steps of gitlab custom runners. The results might be useful invocations beyond Gitlab's scope of application.

I begin with a chroot which will be the base for our build environments:

debootstrap --variant=minbase --include=git,build-essential buster workdir
Fully ephemeral nspawn

This would be fantastic: set up a reusable chroot, mount readonly, run the CI in a working directory mounted on tmpfs. It sets up quickly, it cleans up after itself, and it would make prepare and cleanup noops:

mkdir workdir/var/lib/gitlab-runner
systemd-nspawn --read-only --directory workdir --tmpfs /var/lib/gitlab-runner "$@"

However, run gets run multiple times, so I need the side effects of run to persist inside the chroot between runs.

Also, if the CI uses a large amount of disk space, tmpfs may get into trouble.

nspawn with overlay

Federico used --overlay to keep the base chroot readonly while allowing persistent writes on a temporary directory on the filesystem.

Note that using --overlay requires systemd and systemd-container from buster-backports because of systemd bug #3847.


mkdir -p tmp-overlay
systemd-nspawn --quiet -D workdir \

I can run this twice, and changes in the file system will persist between systemd-nspawn executions. Great! However, any process will be killed at the end of each execution.


I can give a name to systemd-nspawn invocations using --machine, and it allows me to run multiple commands during the machine lifespan using machinectl and systemd-run.

In theory machinectl can also fully manage chroots and disk images in /var/lib/machines, but I haven't found a way with machinectl to start multiple machines sharing the same underlying chroot.

It's ok, though: I managed to do that with systemd-nspawn invocations.

I can use the --machine=name argument to systemd-nspawn to make it visible to machinectl. I can use the --boot argument to systemd-nspawn to start enough infrastructure inside the container to allow machinectl to interact with it.

This gives me any number of persistent and named running systems, that share the same underlying chroot, and can cleanup after themselves. I can run commands in any of those systems as I like, and their side effects persist until a system is stopped.

The chroot needs systemd and dbus for machinectl to be able to interact with it:

debootstrap --variant=minbase --include=git,systemd,systemd,build-essential buster workdir

Let's boot the machine:

mkdir -p overlay
systemd-nspawn --quiet -D workdir \
    --machine=test --boot

Let's try machinectl:

# machinectl list
test    container systemd-nspawn debian 10      -

1 machines listed.
# machinectl shell --quiet test /bin/ls -la /
total 60

To run commands, rather than machinectl shell, I need to use systemd-run --wait --pipe --machine=name, otherwise machined won't forward the exit code. The result however is pretty good, with working stdin/stdout/stderr redirection and forwarded exit code.

Good, I'm getting somewhere.

The terminal where I ran systemd-nspawn is currently showing a nice getty for the booted system, which is cute, and not what I want for the setup process of a CI.

Spawning machines without needing a terminal

machinectl uses /lib/systemd/system/systemd-nspawn@.service to start machines. I suppose there's limited magic in there: start systemd-nspawn as a service, use --machine to give it a name, and machinectl manages it as if it started it itself.

What if, instead of installing a unit file for each CI run, I try to do the same thing with systemd-run?

systemd-run \
  -p 'KillMode=mixed' \
  -p 'Type=notify' \
  -p 'RestartForceExitStatus=133' \
  -p 'SuccessExitStatus=133' \
  -p 'Slice=machine.slice' \
  -p 'Delegate=yes' \
  -p 'TasksMax=16384' \
  -p 'WatchdogSec=3min' \
  systemd-nspawn --quiet -D `pwd`/workdir \
    --machine=test --boot

It works! I can interact with it using machinectl, and fine tune DevicePolicy as needed to lock CI machines down.

This setup has a race condition where if I try to run a command inside the machine in the short time window before the machine has finished booting, it fails:

# systemd-run […] systemd-nspawn […] ; machinectl --quiet shell test /bin/ls -la /
Failed to get shell PTY: Protocol error
# machinectl shell test /bin/ls -la /
Connected to machine test. Press ^] three times within 1s to exit session.
total 60

systemd-nspawn has the option --notify-ready=yes that solves exactly this problem:

# systemd-run […] systemd-nspawn […] --notify-ready=yes ; machinectl --quiet shell test /bin/ls -la /
Running as unit: run-r5a405754f3b740158b3d9dd5e14ff611.service
total 60

On nspawn's side, I should now have all I need.

Next steps

My next step will be wrapping it all together in a gitlab runner.

Enrico Zini: Gitlab runners with nspawn

22 January, 2021 - 23:20

This is a first post in a series about trying to setup a gitlab runner based on systemd-nspawn. I published the polished result as nspawn-runner on GitHub.

The goal

I need to setup gitlab runners, and I try to not involve docker in my professional infrastructure if I can avoid it.

Let's try systemd-nspawn. It's widely available and reasonably reliable.

I'm not the first to have this idea: Federico Ceratto made a setup based on custom runners and Josef Kufner one based on ssh runners.

I'd like to skip the complication of ssh, and to expand Federico's version to persist not just filesystem changes but also any other side effect of CI commands. For example, one CI command may bring up a server and the next CI command may want to test interfacing with it.

Understanding gitlab-runner

First step: figuring out gitlab-runner.

Test runs of gitlab-runner

I found that I can run gitlab-runner manually without needing to go through a push to Gitlab. It needs a local git repository with a .gitlab-ci.yml file:

mkdir test
cd test
git init
cat > .gitlab-ci.yml << EOF
  - env | sort
  - pwd
  - ls -la
git add .gitlab-ci.yml
git commit -am "Created a test repo for gitlab-runner"

Then I can go in the repo and test gitlab-runner:

gitlab-runner exec shell tests

It doesn't seem to use /etc/gitlab-runner/config.toml and it needs all the arguments passed to its command line: I used the shell runner for a simple initial test.

Later I'll try to brew a gitlab-runner exec custom invocation that uses nspawn.

Basics of custom runners

A custom runner runs a few scripts to manage the run:

  • config, to allow to override the run configuration outputting JSON data
  • prepare, to prepare the environment
  • run, to run scripts in the environment (might be ran multiple times)
  • cleanup to clean up the environment

run gets at least one argument which is a path to the script to run. The other scripts get no arguments by default.

The runner configuration controls the paths of the scripts to run, and optionally extra arguments to pass to them

Next steps

My next step will be to figure out possible ways of invoking nspawn for the prepare, run, and cleanup scripts.

Russell Coker: Links January 2021

21 January, 2021 - 10:50

Krebs on Security has an informative article about web notifications and how they are being used for spamming and promoting malware [1]. He also includes links for how to permanently disable them. If nothing else clicking “no” on each new site that wants to send notifications is annoying.

Michael Stapelberg wrote an insightful posts about inefficiencies in the Debian development processes [2]. While I agree with most of his assessment of Debian issues I am not going to decrease my involvement in Debian. Of the issues he mentions the 2 that seem to have the best effort to reward ratio are improvements to mailing list archives (to ideally make it practical to post to lists without subscribing and read responses in the archives) and the issues of forgetting all the complexities of the development process which can be alleviated by better Wiki pages. In my Debian work I’ve contributed more to the Wiki in recent times but not nearly as much as I should.

Jacobin has an insightful article “Ending Poverty in the United States Would Actually Be Pretty Easy” [3].

Mark Brown wrote an interesting blog post about the Rust programming language [4]. He links to a couple of longer blog posts about it. Rust has some great features and I’ve been meaning to learn it.

Scientific America has an informative article about research on the spread of fake news and memes [5]. Something to consider when using social media.

Bruce Schneier wrote an insightful blog post on whether there should be limits on persuasive technology [6].

Jonathan Dowland wrote an interesting blog post about git rebasing and lab books [7]. I think it’s an interesting thought experiment to compare the process of developing code worthy of being committed to a master branch of a VCS to the process of developing a Ph.D thesis.

CBS has a disturbing article about the effect of Covid19 on people’s lungs [8]. Apparently it usually does more lung damage than long-term smoking and even 70%+ of people who don’t have symptoms of the disease get significant lung damage. People who live in heavily affected countries like the US now have to worry that they might have had the disease and got lung damage without knowing it.

Russ Allbery wrote an interesting review of the book “Because Internet” about modern linguistics [9]. The topic is interesting and I might read that book at some future time (I have many good books I want to read).

Jonathan Carter wrote an interesting blog post about CentOS Streams and why using a totally free OS like Debian is going to be a better option for most users [10].

Linus has slammed Intel for using ECC support as a way of segmenting the market between server and desktop to maximise profits [11]. It would be nice if a company made a line of Ryzen systems with ECC RAM support, but most manufacturers seem to be in on the market segmentation scam.

Russ Allbery wrote an interesting review of the book “Can’t Even” about millenials as the burnout generation and the blame that the corporate culture deserves for this [12].

Related posts:

  1. Links January 2020 C is Not a Low Level Language [1] is an...
  2. Links January 2014 Fast Coexist has an interesting article about the art that...
  3. Links January 2013 AreWomenHuman has an interesting article about ViolentAcrez and the wide...

Steinar H. Gunderson: How others program

21 January, 2021 - 01:57

How do others program? I realized today that I've never actually seen it; in more than 30 years of coding, I've never really watched someone else write nontrivial code over a long period of time. I only see people's finished patches—and I know that the patches I send out for review sure doesn't look much like the code I initially wrote. (There are exceptions for small bugfixes and the likes, of course.)

It's not like I'm dying to pair program with someone (it sounds like an incredibly draining task), and I would suppose what goes on on a coding livestream doesn't necessarily match what would happen off-stream, but it was a surprising thought.

Molly de Blanc: Inauguration Pie

21 January, 2021 - 00:07

How can I put four years into a pie? I’m thinking of Inauguration Day 2017 through to today, Inauguration Day 2021. In truth things started back in 2015, when Donald Trump announced his run for the United States’ presidency, and I don’t know how long things will continue past the moment when President-Elect Joe Biden becomes President Joe Biden.

For the United States, it’s been a hell of a time. For the world, it’d been even worse. Every generation thinks that they lived through more than anyone else, that they had it worse. I had a Boomer tell me that the existential stress of COVID is nothing compared to the Vietnam War. I’m sure when we are living through a global water crisis, I’ll tell the kids that we had it bad too. Everyday I listen to the radio and read Twitter, aware that the current state of endless wars – wars against terrorism and drugs, organized crime and famine, climate change and racism – is global, and not limited to just what’s happening to and around me. That makes it feel worse and bigger and I wonder if earlier generations can really grasp how big that is.

The last four years brought me in closer working relationships with people in India and Nigeria. I would call these people my friends in that if they were in town I would want to see them and show them around. Most of them I would offer a space in my small apartment, in case they needed somewhere to sleep and wanted to save the money. We chat, though we only have the internet as opposed to elevator rides in tall office buildings and slow walks down to the shops during lunch breaks.

From these relationships I have learned very little about life in India or Nigeria, and I only visited India separately from any of my colleagues there. (I went for a wedding. My visa to Nigeria was denied on account of a medical issue.) But, I follow these people on social media and see what they share, the same political and social utterances that could be the same here or virtually any other place, as long as we replace the right keywords. Exchange the name of one leader, conservative party, or government unit for another. When I first saw the #EndSARS hashtag show up, I thought the images were from Black Lives Matter protests. Stop police brutality.

And that was only in the last few months.

I’ve had three jobs since Trump first announced his candidacy in three very different places. In the first I felt like I wasn’t able to talk about the sexism and discrimination I was dealing with in the office, and how much more so my views on an organizational partnership with a government whose policies I strongly disagreed with. In the second I was able to talk about these things, but there was nothing to do about them.

I’ve been in love and had my heart broken three times in three very different ways that all came down to someone valuing someone else more than they valued me. Can I bake heartbreak into a pie? Is it even fair to distract from the political world with my own loss?

What about COVID-19? There’s bitterness and anger and tears and pain – emotional and physical. There is desperation and desolation and loneliness. Covid has colored everything during the past year. It is a burden our new political leaders will take on. Biden and Harris, all of the new people in Congress, and everyone else who has taken on an elected position now must content with Covid with new levels of responsibility. Not only do their decisions affect the people they come into contact with, they now affect everyone their policies touch and perhaps even more than that.

The government hired people to build walls. Our government approved it and people willingly took on the job of building those walls. Families were separated. Children were placed in inhumane conditions; children were tortured. Remember when the guards at border detention facilities were raping children? Remember when children had guards? Women were forcefully operated upon and had their bodies permanently changed without their permission, against their desires. People were executed by the state.

There were so many things I’ve lost track of them all. I remember bits and pieces as I write this, coming back to me like singing a song I haven’t thought about in years. With each line, I remember another one. Being worried about coming home from Cuba, when the visitation rules were changed in the middle of my trip. Climate change, again and again. Pollution and microplastics and watching the country being broken into pieces and sold off in the name of economy and progress. People losing their access to healthcare, through clinics closing down and loss of insurance.

What do you bake into a pie that tastes like sedition? What are the flavors of loss and racism and hate? How to you balance the sourness with subtle hints of hope, which feels to tender and fragile? Do we pair equal parts of the palatable with the unpalatable, in the name of our neatly divided senate?

I have hope, of course I have hope, and I have always had hope, but now it feels thinner than ever, like a ganache or a caramel after your hand slips and you pour too much cream in. A custard or compote or curd that that refuses to thicken no matter how long you cook it. I see that things could be better, but better does not mean good and better does not mean enough.

So I will put my hope into this pie. I put my pain and anger into the dough. I will put my tears and helplessness and bitterness into the filling. I will cover it sweetness and the delicate hope I’ve spun out of sugar. Soon I will bake it and share it with the three other people I see because the most important thing about surviving these past years, these past months and weeks and days, is that we did it together. We will commiserate on what we’ve overcome, and we will share our hope and the sweetness of the moment, as the spun sugar dissolves on our tongues. There is so much we have left to do, so much we must do. We will be angry in the future, we may be angry later today, but until then, we have pie.

Jaldhar Vyas: To Mega Therion

20 January, 2021 - 23:33

Rapha&#235;l Hertzog: Freexian’s report about Debian Long Term Support, December 2020

20 January, 2021 - 16:39

Like each month, have a look at the work funded by Freexian’s Debian LTS offering.

Debian project funding

In December, we put aside 2100 EUR to fund Debian projects. The first project proposal (a improvement for the security team) was received and quickly approved by the paid contributors, then we opened a request for bids and the bid winner was announced today (it was easy, we had only one candidate). Hopefully this first project will be completed until our next report.

We’re looking forward to receive more projects from various Debian teams! Learn more about the rationale behind this initiative in this article.

Debian LTS contributors

In December, 12 contributors have been paid to work on Debian LTS, their reports are available:

  • Abhijith PA did 7.0h (out of 14h assigned), thus carrying over 7h to January.
  • Ben Hutchings did 16.5h (out of 16h assigned and 9h from November), thus carrying over 8.5h to January.
  • Brian May did 10h (out of 10h assigned).
  • Chris Lamb did 18h (out of 18h assigned), thus carrying over h to January.
  • Emilio Pozuelo Monfort did 16.5h (out of 26h assigned), thus carrying over 9.5h to January.
  • Holger Levsen did 3.5h coordinating/managing the LTS team.
  • Markus Koschany did 26h (out of 26h assigned and 10.75h from November), thus carrying over 10.75 h to January.
  • Ola Lundqvist did 9.5h (out of 12h assigned and 11h from November), thus carrying over 11.5h to January.
  • Roberto C. Sánchez did 18.5h (out of 26h assigned and 2.25h from November) and gave back the remaining 9.75h.
  • Sylvain Beucler did 26h (out of 26h assigned).
  • Thorsten Alteholz did 26h (out of 26h assigned).
  • Utkarsh Gupta did 26h (out of 26h assigned).
Evolution of the situation

December was a quiet month as we didn’t have a team meeting nor any other unusual activity and we released 43 DLAs.

The security tracker currently lists 30 packages with a known CVE and the dla-needed.txt file has 25 packages needing an update.

This month we are pleased to welcome Deveryware as new sponsor!

Thanks to our sponsors

Sponsors that joined recently are in bold.

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Kentaro Hayashi: is sponsored by FOSSHOST

20 January, 2021 - 09:36

Today, we are pleased to announce that has migrated to FOSSHOST

FOSSHOST provides us a VPS instance which is located at OSU Open Source Lab. It improves a lack of enough server resources then service availability especially.

About is a experimental service to demonstrate how to improve user experience with finding and fixing Debian unstable related bugs for making "unstable life" comfortable.

Thank FOSSHOST for sponsoring,


Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้