Latest 10 recent news (see index)
August 13, 2019
xbps bug results in missing /bin/sh
Due to a bug in xbps there was an issue this morning where /bin/sh disappeared after an update.
The bug was fixed quickly, but there’s a 2h window where an update may have resulted in a broken system.
If you’re affected by this issue you may experience error messages like these during boot:
runit: fatal: unable to start child: /etc/runit/1 file does not exist
These are the steps to recover your system:
Case 1: System is still running and you have a working shell open
Run the following command as root:
# xbps-install -Su
Afterwards your system should update xbps and recreate /bin/sh
Case 2: System has rebooted or no shell is opened anymore
Restart your system
GNU GRUB version 2.02
┌────────────────────────────────────────────────────────────────────────────┐
│*Void GNU/Linux │
│ Advanced options for Void GNU/Linux │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Use the ↑ and ↓ keys to select which entry is highlighted.
Press enter to boot the selected OS, `e' to edit the commands
before booting or `c' for a command-line.
Once grub comes up, select the kernel you want to boot and press E.
GNU GRUB version 2.02
┌────────────────────────────────────────────────────────────────────────────┐
│ search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --\│↑
│hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 XXXXXXXX-XXXX-XXXX-XXXX-\│
│XXXXXXXXXXXX │
│ else │
│ search --no-floppy --fs-uuid --set=root XXXXXXXX-XXXX-XXXX-XXXX-X\│
│XXXXXXXXXXX │
│ fi │
│ echo 'Loading Linux 4.19.15_1 ...' │
│ linux /boot/vmlinuz-4.19.15_1 ro loglevel=4 slub_debug=P pa\│
│ge_poison=1 rd.break │
│ echo 'Loading initial ramdisk ...' │
│ initrd /boot/initramfs-4.19.15_1.img │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Minimum Emacs-like screen editing is supported. TAB lists
completions. Press Ctrl-x or F10 to boot, Ctrl-c or F2 for
a command-line or ESC to discard edits and return to the GRUB menu.
find the line that starts with linux /boot/... and add rd.break at the end of the line.
Make sure it is seperated with a space from the rest of the line
Afterwards Press Ctrl + X to boot the configuration.
Dropping to debug shell.
dracut:/#
Once you’ve got a shell execute the following commands:
dracut:/# mount -o remount,rw /sysroot
dracut:/# chroot /sysroot xbps-alternatives -s bash
dracut:/# exit
Afterwards the system should work as expected.
Please use xbps-install -Su to fetch the newest xbps version that fixes this bug.
If it doesn’t help
Join over on #voidlinux in freenode or ask on reddit.
June 20, 2019
XBPS 0.54 Released
XBPS 0.54 is released. This release includes many new features and a plethora of bug fixes. Some notable fixes include:
- Improved conflict checking
- Additional compression formats including zstd
- Fixes to the alternatives system
- New binaries replacing portions of xbps-uhelper
- Over 30 new test cases
New binaries have also been uploaded to the static/ directories of all mirrors.
As always you can read the complete changelog on GitHub and file issues at https://github.com/void-linux/xbps/issues.
April 01, 2019
New Homepage
After years of development and beta testing in various focus groups, we’re pleased to announce the new homepage design. No animals were harmed during development.
February 12, 2019
VoidLinux.eu Is Not Ours
We would like to warn people of a domain name that is no longer under Void
Linux control. voidlinux.eu lapsed in its original registration, and was
purchased by an unknown 3rd party before Void Linux could regain ownership. At
this time, please assume that anything involving voidlinux.eu is not related
to Void Linux, and should be considered potentially malicious. Of course, if
the person who owns the domain now would like to transfer it to our control,
we’d be grateful, and will update voidlinux.org to indicate if this happens.
Our official domain is VoidLinux.org.
February 03, 2019
Cross compilation support for gobject typelibs
Thanks to the work of maxice8 we’re pleased to announce cross compiling support for gobject-introspection and packages that depend on this tool. This is a big step forward to support more packages through cross compiling and stay future proof for glib development.
maxice8 put together a comprehensive post about his work. This article will be higher level overview of our work in this field.
What are gobject and typelibs?
gobject is an abstract description of types defined in glib. Glib is used on a wide range of application and libraries, most notably gtk. Glib itself is written in C but it’s possible to provide dynamic language bindings to other languages such as python.
This mechanism is not builtin into glib, but instead is provided by the gobject-introspection tool. This tool scans both the source and the binary blob of a library and creates a metadata file that is used to provide type information for other language bindings. For a deeper dive into gobject-introspection please consider the docs at readthedocs.io
The problem
When it comes to Void, we have high demands on portability of applications. Our armv6l, armv7l and aarch64 platforms a completely and exclusively cross compiled, meaning they are built on an x86_64 host. This leads to an interesting problem with gobject-introspection which by design needs to run on the same platform as the produced binaries are targeted.
Unfortunately, as already stated this has been a design decision of this software and we can’t do anything to change this constraint itself.
Furthermore, during the last few years the Gnome community drifted towards extensively using gobject-introspection in their products. This led to the breakage of more and more applications in the gnome-ecosystem.
The solution
During the last few months we considered different solutions to this problem. This first proposal to not support gir through cross compilation and only allow it through native build became more and more unsatisfying as the number of packages using this mechanism increased over time.
The second approach which was the followup to the one described above was to add native builders to the system and build those packages on those native builders. The issue was here that this would require a lot of infrastructure work and added a lot of complexity.
The third solution and the one we chose was to use the userspace emulation features of Qemu to emulate the target system only for those calls that needed to be on the target platform. The yocto project is already using this approach to cross compile Gnome Applications to other platform. We reused many of their tooling for void-packages. Nontheless, we hit many porting issues - our tooling must run on musl, too - , new bugs were triggered in void-packages - see for example these two posts at maxice8’s blog, and many other small issues needed to be resolved.
Basic support for cross compilation has already landed in void-packages, the musl port is not yet finished, but we expect it to work soon(tm).
maxice8 also prepared a blog post about his porting work on libgusb.
February 03, 2019
The Life of a Pull Request & Where Commit Bits Come From
Sometimes people will join into #voidlinux and ask why changes are
taking so long to get merged. This is an interesting question, and it
boils down into a few parts. In this article we’ll take a look at the
life of a pull request and how it gets from idea to package.
For any package to exist, someone first has to want it. This want is
often expressed as someone in IRC saying “I want to use Void, but I
need package foo” and someone looks at it and decides they will
package and maintain foo. Sometimes this want will manifest as an
issue filled to the void-packages repository on GitHub, and sometimes
it manifests as a “blind” PR showing up for a new package. This last
one is what we’ll follow as it’s where things get interesting.
A Call to Action
When a PR is created, this triggers GitHub to notify people according
to its settings. For some members of the project this will trigger an
email, for some people this will trigger other automation via API, and
up until very recently, the #xbps channel on freenode was NOTICE’d
(this last one is gone as GitHub has removed this functionality with
no clear replacement path).
This notification will hopefully grab the eye of at least one reviewer, who will then open the link to view the PR on GitHub, or will otherwise begin reviewing by their preferred means. Many of our reviewers prefer to pull the PR locally and view it in their editor of choice, or build it locally on more powerful boxes than Travis CI provides.
Changes Requested
This is usually the slow part of getting something accepted to void-packages. This is the part that involves going back and forth on what changes need to be made or what improvements are requested and often involves discussion of potential changes to package policy.
For folks in IRC this often will be a rapid fire exchange of comments in channel or query, and often ends with something like this:
15:30 <bobertlo> i'm making the suggested changes [...]
15:31 <maldridge> bobertlo: ping me when you're ready for review+merge
At this point the ball is back in the author’s court, and the committer is waiting for changes to be made. At this point it’s also considered that a committer is tenuously “assigned” to a PR.
In a good flow, the next thing that happens is another message from the author:
15:53 <bobertlo> maldridge: i pushed those changes
The Reviewer Follows Up
When a reviewer is “assigned” to the PR, it doesn’t really mean that they own it, but there is some expectation that they will follow the work through to merge unless they explicitly state otherwise. Sometimes this looks like a comment on a PR, and other times it looks like a poke in IRC to see if the author is still working on the changes.
At the end of this phase, the reviewer will either approve or dismiss the PR. Usually dismissing a PR is only done if the package is completely unworkable and the author and reviewer have come to an agreement that it won’t be accepted for some concrete reason, but other reasons exist.
Merged
When a package is accepted the reviewer will merge it, and then our automated build infrastructure will kick into action. A webhook from GitHub will signal to our infrastructure that a new change is to be built, and the systems will pull down the changes via git. After it has been ascertained what needs to be rebuilt, the change is dispatched to our builders to begin compiling the new or updated package.
After compilation, the built package is copied back to the build master and is signed, then indexed into the repository for interested users to download. Past this point is a complicated web of rsync that is beyond the scope of this article.
Why does it take so long?
First of all, it doesn’t. When you compare Void’s process to other distributions, the process of getting a package included can be as short as an hour from initial request to installable globally.
The slightly longer answer is that there are bottlenecks. One of the easiest to understand is that there are only so many servers we can build on, and the time it takes to compile packages (especially large ones) has to be taken into account.
The single largest bottleneck though is reviewer loading. In the process that’s described above, reviewers are loosely connected to PRs, and follow them through. While our reviewers are very fast in many cases, they are still human and can only hold so many things at once.
So if the reviewers are the bottleneck, the question logically follows: where do reviewers come from and how do they get their special powers?
Special Powers
Within the Void vernacular, people who can merge changes are referred to generally as people with a commit bit. For those who are curious, this term comes from privileged users on a BSD system often having a “wheel bit”. At the time of this writing, there are 13 people with a commit bit. These people can merge to almost any repository in the organization, but there are a few exceptions. Having a commit bit can also come with other powers, like the ability to op up in IRC, but such additional powers are not automatic, and are beyond the scope of this article.
So how does one get these special powers?
The astute Void follower may already know this answer, as has been documented for some time now on InfraDocs.
The full documentation can be found in the onboarding documentation. But to save the effort of going to that page, we’ll briefly recap it here.
First a person has to be noticed within the project as a good fit for having the ability to merge changes on their own. Usually this means that they’ve been an active contributor continuously for some time and have a history of submitting high quality work.
After an existing committer thinks they’ve found a good candidate, they’ll propose the membership change to the project owners in private. This allows the project owners time to discuss the proposal with the proposer and exchange information without needing to talk publicly. Sometimes there are circumstances that a proposer might not be aware of that may affect if they wish to continue suggesting someone, and this initial conversation gives a time to discuss that.
After this discussion has happened a final decision is made to either accept or reject the proposal. In the event it has been accepted, the candidate is informed and has the final choice to accept.
I’ve Got a Bit, Now What?
Just getting the powers though isn’t enough. People who hold a commit bit have to justify that they have them. This means means either reviewing changes, commenting on PRs, or otherwise advancing the state of the Void. In the past when people have left the project either by explicitly stating they’ve left, or by just not being a part of it for a while, we revoke powers. This helps us keep Void reasonably secure by knowing exactly who all has the ability to push changes to our repositories.
Of course if any of these people were to come back, they’d be welcome to once again demonstrate their skill and again earn the special powers as they did before. Just having had the power at one point is not sufficient cause to be handed it again.
In summary the life of a PR is part of a much larger process of
getting and maintaining a pool of contributors and qualified
reviewers. This process is quite involved, and this post only just
scratches the surface. Interested persons are always encouraged to
reach out to us in #voidlinux on freenode. The author of this post
can always be contacted in #voidlinux as maldridge.
January 31, 2019
The curious case of Python and global variables
Void isn’t all smooth sailing. Sometimes things break in obscure and difficult to troubleshoot ways. This was recently the case when one of our maintainers noticed that certain Python packages weren’t behaving as expected. If you’re curious about how this kind of troubleshooting happens, [maxice8]’s blog post is highly recommended as its a good intro into what its like to troubleshoot things from the perspective of a Void maintainer.
Read the troubleshooting process here.
January 23, 2019
dhcpcd>=7.1.0 update may require manual intervention
Starting with 7.1.0, the dhcpcd(8) package is dropping the 10-wpa_supplicant hook.
Instead of the hook, upstream suggests to build wpa_supplicant(8) with
CONFIG_MATCH_IFACE enabled, this is done in the wpa_supplicant package since version 2.6_14.
Users of the 10-wpa_supplicant hook will need to adjust their systems to guarantee
that their wireless connection keeps working.
The following actions are required when dhcpcd(8) is updated to 7.1.0 for users of the 10-supplicant hook.
- Make sure wpa_supplicant(8) is at least 2.6_14
- Enable the wpa_supplicant(8) service.
Other users should be on the lookout as -M is now used to match all interfaces, using for configuration
the CONF_FILE variable. Setting an specific WPA_INTERFACE is now optional.
December 24, 2018
The Advent of Void: Day 24: 'Twas the Night Before Christmas
‘Twas the Night Before Christmas,
When all through the cluster, not a build was running, not even a revbump. The packages were all signed by the server with care, in hopes that an upgrade soon would be there.
The maintainers were nestled all snug at their desks, while visions of waterfalls danced in their heads; and Gottox in his home and I in mine, had just settled our brains for a long winter break; when out on the frontends there arose such a clatter, I sprang to my terminal to see what was the matter.
Away to my console I flew like a flash, called for my tmux and threw open the logstash. The status page on my screen lent a luster of midday to errors below, when what to my wondering eyes should appear, but a stuck qt5 build and 8 staged SONAMEs.
With a large webengine so slow and so massive, I knew in an instant it must be chromium. More rapid than runit my commands to the system: “Now Ansible! now Grafana! now buildbot and xbulk! On rindex! on snooze! on, ext4 and repo-cleaner! To the top of the graph to the top of the stack now build, build away, build away all!
As disk platters that before the online scrub fly, when they meet with an obstacle always retry, so up to the servers the tasks they all flew, with their mirror of toys and BDFL, too.
And then in a twinkling, I saw in reply the server starting and launching of each single build. As I drew in my buffers, and was closing up shop, down the pipe the json came with a stop. It was padded with null bytes from its start to its end, and its braces were all tarnished with codepages and parity bits; a slice of package it contained in its body, and it looked like a startup just opening its reply. The descriptors how they twinkled, the keys how merry!
A close of a brace and a retcode of 0 soon gave me to know I had
nothing to dread. Buildbot said not a word but went straight to its
work, and filled the mirrors with packages. Waiting for but a moment
before confirming my intent, the BuildBot went on its way; indexes
sprang to their clients, and to the fleet I did signal and away they
all built like the sight seldom seen. But before I C-b d I exclaim
to all users:
Happy Christmas to all, and to all a Good Night!
–maldridge
We hope you’ve enjoyed the Advent of Void. This is a fun project that we’ve done now for two years to try and shed some light on lesser known packages. We’ve got a few honorable mentions that may make their way to the feed over the next few days, but this post concludes the series. Void is a volunteer effort that we enjoy sharing with you, and hopefully you’ve learned some neat new tips and tricks these last 24 days. Our volunteers don’t just make packages and manage infrastructure, we also write fun posts like these (though I recognize I’m a quite poor poet). If you want to become involved and help us keep Void going, join us in #xbps on freenode, but maybe wait until after the holidays to do so.
Enjoy the winter season and the updates that just keep rolling!
December 24, 2018
The Advent of Void: Day 24: gromit-mpx
Have you ever wanted to doodle on a screenshot? Ever? Just a single underline, or an arrow, or something to help point out something about a screenshot? Or maybe during a presentation, on the fly, suddenly you want to point out a particular thing… wouldn’t it be nice to have a tool to help?
Turns out, there is one, a very simple tool to do this. I use it every month.
Gromit-mpx is simple. <F9> to start being able to draw, Shift-Ctrl-<F9> to
clear everything you drew, and Ctrl-<F9> to stop being able to draw (but
leave everything on the screen). Just make sure gromit-mpx is running in the
background, and you are set for all your drawing and annotating needs. Even
people like me, who just run dwm and not with any compositor, I can annotate
my screen quickly.
But with just a few lines, I can clarify what I meant to share. I won’t be winning any art awards, but it works.
Do note that the annotations stick around, even after you scroll the window, or switch to a different screen entirely.
So keep gromit-mpx around, it might be useful someday.
For more information, there is always the gromit-mpx(1) manpage.