Latest 10 recent news (see index)

May 30, 2023

Breaking changes: Pipewire session manager switch, Pipewire and PulseAudio system service removal

Pipewire session manager switch

Void has now dropped the long-deprecated pipewire-media-session session manager from its pipewire package, bringing it inline with the upstream default configuration. If you are currently using pipewire, you must migrate to wireplumber or pipewire will cease to function properly. Refer to Void documentation if you need guidance when making this change.

Pipewire and PulseAudio system service removal

The oft-confusing services for pipewire, pipewire-pulse, wireplumber, and pulseaudio have been removed from the pipewire, wireplumber, and pulseaudio packages because they were experimental and should not have been used for almost all use-cases.

If you are currently using those services and still wish to do so, replacements for the pipewire and pulseaudio services can be found in /usr/share/examples/$pkgname/sv/. Otherwise, it is recommended to migrate to another method of launching pipewire. Refer to Void documentation if you need guidance.

February 11, 2023

New Repo: Fastly CDN

In our last post we showed you how to quickly change your mirror using xmirror. In this post we’ll give you a reason to use it, and talk a little more about how mirrors work and how packages get from our servers, to your computer.

Before we can mirror packages, we first need to build some. Void uses a worker-based build architecture where a central controller dispatches build tasks to individual servers that own the builds for specific architectures. At the time of writing, Void makes use of discrete builders for aarch64 targets, assorted musl targets, and assorted glibc targets. The breakdown is as follows:

• a-fsn-de
  • x86_64
  • i686
  • armv6l
  • armv7l
• b-fsn-de
  • aarch64
  • aarch64-musl
• a-hel-fi
  • x86_64-musl
  • armv6l-musl
  • armv7l-musl

Each build server drives, via automation, a standard git checkout of the void-packages repo. This in turn results in built binary packages ready for installation in the path /hostdir/binpkgs on each of the build machines. To actually be useful, however, the packages need to be aggregated and then signed, then copied out to servers near to end users such that packages are quick to download and install whenever required.

Packages are aggregated via nomad managed rsync tasks to a-fsn-de. Since a-fsn-de already hosts several architectures, its packages don’t need to be moved. You might recognize the target directories from the repo URL structure. The packages originating on a-hel-fi are copied to /hostdir/binpkgs/musl and the packages from b-fsn-de are copied to /hostdir/binpkgs/aarch64. Once the packages are all in one place, they can be signed. This is also handled by a nomad managed batch task.

Once signed, a complete, ready to distribute package collection exists on a-fsn-de, however this isn’t where any mirror synchronizes from, nor is it where end users obtain packages from. The first real “mirror” in the chain with the full contents, including live images, docs, and other mirror contents is on a-hel-fi and is sometimes referred to by the Void team as the “Shadow Repo”. When we make large builds that we know in advance will cause issues for end users, we disconnect all downstream repos from the shadow repo and this allows us to run large builds without impacting user’s ability to install or update already extant packages.

Tier 1 (Void Operated) mirrors synchronize directly from the Shadow Repo, again via nomad managed batch tasks. All downstream mirrors synchronize from one or more tier 1 mirrors, with one notable exception which we’ll come back to. These mirrors are operated by universities, companies, and individuals who desire to have a copy of the Void repository closer to them. This allows for faster installs, faster updates, and in many cases more efficient bandwidth usage where a mirror is able to be co-located with multiple Void users.

By and large, these mirrors synchronize using rsync on cron timers. Some synchronize very frequently, as frequently as every 15 minutes. Some synchronize more slowly, only once a day. And some mirrors often appear broken and don’t appear to have synced at all. How can we possibly know this? Well we drop a file into the root of the mirror at the Shadow level with a timestamp. By watching the value in this file, we can tell how old the contents of any downstream repo are. All this information is exposed in our mirror dashboard. The “Origin” referenced in that dashboard is a slight misnomer, its actually showing the time behind now.

Having multiple mirrors is great, but ensuring that a mirror nearby to a user who wants to update, and make sure they’ve configured and are using it is a bit harder. What we really want is a proxy that will always find the nearest mirror and fetch packages from that location for a user. Long-time users of Void may remember auto.voidlinux.org which was an early attempt at this. Due to limitations in XBPS itself, and limitations in the way that we are able to introspect mirrors, this service was eventually retracted. What we actually want is a network of servers everywhere well connected to networks that users are on, and then with a good connection back to at least one of the Void operated mirrors. This, as you might have guessed, is a CDN.

As mentioned in the Fast Forward post, Void has generously been sponsored by Fastly, which has allowed us to provision a new repository URL that leverage’s Fastly’s global network to provide what should be the generally optimal mirror regardless of where in the world any particular end user exists. The Fastly mirror does not sync, nor does it have a concept of file storage that we manage as the project. It is for all intents and purposes an extremely large high-speed cache, and when you request a package from Fastly, the package will either be returned from one of Fastly’s servers, or it will be streamed to you via the Fastly network while being simultaneously fetched from one of Void’s backend servers. The very first download of a package may be slower than if you downloaded it from Void directly, but all subsequent fetches will be extremely fast. Since the package distribution follows a sort of curve of popularity ranging from the common packages that make up desktop environments, the base system, and popular software suites down to less commonly installed packages and rarely updated libraries, the cache will usually be hot for the most commonly installed packages!

So to recap, packages are built on servers, copied to a central server, signed, copied to a shadow mirror, copied to a tier 1 mirror, possibly copied to downstream mirrors, and then installed on end systems. Here’s a graphic:

We hope you’ve enjoyed this look into what it takes to get packages from us to you, but more importantly, we’re pleased to announce now the general availability of https://repo-fastly.voidlinux.org/ which should be the generally fastest mirror for most users. This mirror is available now in xmirror under the World region.

February 11, 2023

New utility for selecting XBPS mirrors

If you’ve ever had trouble manually updating the mirror XBPS uses, fear no more! You can now use the xmirror(1) utility from the xmirror package to select a mirror, either interactively (by running xmirror with root privileges) or directly using xmirror --set.

xmirror will make switching to the new Fastly-sponsored mirror extremely easy to do.

February 09, 2023

Minor breaking change in service logging for several packages

As of this change in void-packages, all services provided by packages should start to include log sub-services that use vlogger(8) as they are updated, if they did not already. This means that service logs for all services should go to syslog now, where they can be captured by a syslog daemon.

However, there are a few services that manually log to /var/log/$SERVICE_NAME:

• dnscrypt-proxy
• dqcache (from dq)
• preload
• radicale
• discosrv and relaysrv (from syncthing)

These services have been updated to use this new system, so they will no longer log to that directory. If you wish to retain the previous behavior, you can set up /etc/vlogger like shown here:

#!/bin/sh
exec svlogd /var/log/$1

January 19, 2023

Void Accepted to Fastly Fast Forward!

Did you know that Void has over 20 mirrors? We have mirrors all over the world, but just having a bunch of servers isn’t enough to effectively deliver package updates to all Void users. A mirror that is nearby can have extremely good performance if you know it’s there and switch to it, but for many people what we would like to offer is just a URL that works anywhere in the world to provide the best download experience available in that location. When you look at what we’re trying to achieve, its pretty clear we’d be trying to build a content delivery network (CDN) for Void.

Rather than re-inventing the wheel, we reached out to the team at Fastly to see if they’d be interested in working with us to improve the default package experience for Void users globally. We’re excited to announce that the answer is yes; Void has been accepted to the Fastly Fast Forward program. As part of this project, we’ll be provisioning a new repo URL that will retrieve packages via Fastly’s global CDN.

Stay tuned over the next few weeks for the new mirror to become live, and a post about how Void’s mirror infrastructure works!

December 01, 2022

US Mirror Issues

The US mirror, repo-us.voidlinux.org, is currently having hardware issues and is no longer syncing with the other mirrors for the time being. Until this is fixed, switching to another mirror is recommended. There are several other mirrors located in the US that are still operational.

October 16, 2022

New Images! (October 2022 Edition)

We’re pleased to announce that the 20221001 image set has been promoted to current and is now generally available.

You can find the new images on our downloads page and on our many mirrors.

Special thanks for this image set goes out to @CameronNemo for work in fixing some of the issues with networking in the installer and @paper42 for various improvements to the live image contents.

Also in this release, the Raspberry Pi platform images are now condensed into one image per architecture. See here for more details about which image to use for which Raspberry Pi model.

You may verify the authenticity of the images by following the instructions on the downloads page, and using the following signify key information:

untrusted comment: This key is only valid for images with date 20221001. public key
RWQ0DEc5FwYgp8wuGTRe3IWJGagpbeOpPqfSQbPIJie9GP8oBybejTqs

September 30, 2022

Hacktoberfest 2022

Are you ready for Hacktoberfest 2022? Void Linux is! We’re excited to be participating for our 6th year. Contributions that help to address our out-of-date packages queue are especially welcome. This is a great way to dip your feet into the world of Linux distro package management and what happens behind the scenes to provide a wide selection of packages and make sure your system remains up to date.

Updating packages is very easy. You can select a package from the list of out of date packages and update it using the tools in the void-packages repo. The manual might be of assistance when you are updating packages.

As a general rule, we recommend that newcomers to the Void Linux project steer clear of “structural” packages unless you have specific domain knowledge that qualifies you to work on high-risk packages. When selecting a package to update, prefer packages registered to orphan@voidlinux.org. These packages are otherwise unmaintained, and your contribution will have a bigger impact. You can update packages that have a maintainer assigned, but understand that conflicting changes between a maintainer and contributor will be resolved at the discretion of Void staff.

Here are some useful tips when updating packages:

• While we’re not completely opposed to PRs that add new packages, you’re much more likely to get your PR approved and merged if it’s a well written update.
• Don’t PR broken code. Our maintainers are much less likely to give a second look to a PR that didn’t build when it was submitted.
• While it’s possible to run xbps-src from an alien distro, this isn’t really supported. If you’re a seasoned Linux user and want to try Void, now is the time!
• The update list is sometimes wrong. We’d love to get patches that improve its reliability by ignoring beta versions or adding checks to packages that are not correctly detected as out of date.
• If you have expertise in C, GNU Autotools, or other build systems, taking a look at projects that we’ve marked as incompatible with cross compilation and fixing the upstream issue can be an amazing contribution that impacts more than just Void.

Want to contribute but don’t know how to code? No sweat! We have a documentation project that’s managed in git and can help you learn how to use the tools of the trade without needing to simultaneously learn how to manage our package build system. Docs contributions should be in the style of the manual, so make sure you understand the manual and feel free to open an issue or ask on IRC before starting on a larger contribution to make sure your change can be accepted.

We look forward to working with the amazing world of open source developers this month to improve Void and continue our high standards for quality and reliability. To ensure your PR has the best chance at being accepted, feel free to reach out for help as explained in the manual. Together, we can make this a high-impact Hacktoberfest.

May 27, 2022

New Mirror Default

The default mirror has been updated to https://repo-default.voidlinux.org. If you wish to specify a mirror that is nearer to you geographically you can find the full list of currently active mirrors here: https://docs.voidlinux.org/xbps/repositories/mirrors/index.html.

October 03, 2021

US Mirror Retirement

The alpha.us.repo.voidlinux.org mirror has been retired. Users should switch to https://repo-us.voidlinux.org for continued service out of the central US. As part of the switch the US tier one mirror has gained TLS, and is running on a more reliable host.

All contributors with in-flight PRs should rebase to ensure that the latest URL is reflected in your branch’s CI configuration.