Nov 272015

Recently I have received a number of emails regarding breakage in sbotools with the latest development version of Slackware. In fact, I have been surprised by the amount of emails; I did not realize that so many folks are using the tools now. Unfortunately I am not one of those people, though, since, at present, I do not have any systems running Slackware. Currently maintainership has been handed over to pink_mist, a long-time friend of the project who already has a new version out with a fix for the compatibility issue with -current. He’s got an sbotools site up and running which you should refer to in future regarding the project. There’s no doubt that he’ll take good care of the code moving forward – and no doubt that it needs it.

May 242014

cidrcalc is a tool I hacked up a couple days ago to calculate CIDR prefixes from traditional netmasks and vice versa. I needed a simple tool to translate back and forth for scripting purposes while working on DavrOS, but this has obvious uses beyond that – no need to reach for Google to find a CIDR calculator to go back and/or forth trivially, for example – so I figured I would make a proper release of it. The code is POSIX compatible and has been compiled from the source tarball with no changes on Slackware, FreeBSD, and OS X in addition to its native environment. It will install under /usr/local by default; modify the Makefile if you’d like to use a different prefix.

Examples are as follows:
(0606){bm6}(~): cidrcalc --usage
Usage: cidrcalc [netmask|/cidr]
(0606){bm6}(~): cidrcalc
(0606){bm6}(~): cidrcalc /5

Credit goes to this thread for the methods I used.

Moving forward, I may add a flag to report instead how many IP addresses are in a subnet provided its netmask or CIDR prefix, and possibly a calculator to and from hex. Or I may leave it more or less as is…

Jan 312014

DavrOS 0.2 is now released. It’s been a couple months since the last release, and a lot has changed in that time. DavrOS still has a long way to go, but considerable ground has been covered in the time since the initial release. Many missing things have been added, and many features have been implemented. Here are some of the highlights:

  • Added pam, attr, acl, lvm, mdraid, pciutils, usbutils, ntp, cron, ethtool, logrotate, and probably a few other things I’m forgetting.
  • Added support for gpt partitions via gptfdisk, well tested through actual usage at this point.
  • Forked GNU df to create a POSIX-compliant df command.
  • Forked systemd’s udev to ddev, removed unreasonable ethernet device naming.
  • Generate /boot/grub/grub.cfg automatically from installed kernels and the contents of /etc/grub/{header,params,footer} via mkgrubcfg script.
  • Added support for installation from USB media.

We’ve made some very small modifications to logrotate, and may maintain our own fork moving forward, if it should begin to make sense to do so.

LVM and mdraid are not supported in the DavrOS installer at this time – it’s completely incapable of handling them. The setup script itself will not gain this capability – the variety of possible file system/partition/volume configurations are significant enough to warrant a separate script. Once that work is done the setup script will be made aware of it.

Our df command is intended to behave in accordance with the POSIX specification, which includes showing inode capacity by default, a huge win in usability in my opinion. We expect to maintain this code as a fork moving forward, though we may pull in certain changes from coreutils from time to time; it is doubtful that GNU utilities such as df will ever by POSIX compatible by default. That said, we are greatly in debt to the authors of GNU df.

A number of other pieces of coreutils have been completely replaced, either with trivial but POSIX-compliant implementations or ports from FreeBSD – doing so has many benefits for us, such as reducing the build time, reducing the size of the build tree, reducing the fragility of the build, and in many cases increasing POSIX compliance. The downside to such replacements is that in some cases we lose some of the robust i18n which GNU provides – but we have a plan to sort that out moving forward as well.

As far as ddev goes, the way we handle ethernet device names is the only really significant difference between ddev and udev. An effort will be made to at least maintain compatibility with udev rules files, if not the rest. We will, however, be maintaining this code as a fork moving forward, and have additional plans to enhance how ddev handles ethernet device names. Speaking of which, ridiculous names like “eno13677776” and “enp3s01” have been thrown out in favour of simply “en0”, “en1”, etc. The kernel’s numbering is maintained, only the letters are changed – we’ve never seen an actual case where the kernel can’t consistently number the same devices the same way every time. The device renaming itself may seem pointless, but this is in support of planned changes moving forward – it made more sense to make the disruptive naming change now rather than later. Rules in /etc/udev/rules.d which tie ethernet device names to MAC addresses are still supported, should this functionality be required or desired. We do not, however, generate such rules by default. We do provide an example.

And last but not least, the installation media is now delivered as a hybrid ISO, and the setup script doesn’t care whether the media is USB, CD-ROM, or avian carrier – it should behave the same in any case. USB installation is now very well tested. Simply dd the .iso to a USB drive.

Some of the things in the works moving forward will be getting rid of sysvinit-style startup scripts and their symlink pools (what we’ll replace them with is still being tested/decided/worked on, but that’s the next thing to be done), getting pkgsrc – or, as may be necessary, a fork of pkgsrc – properly working and available, adding “the rest” of what’s missing and cleaning up what’s present, implementing a binary update mechanism, and, well, really much more.

DavrOS 0.2 is still very much alpha/beta – as the version number indicates – and we’d very much like to hear from anyone giving this operating system a go.

Nov 272013

sbotools 1.8 is now released, bringing support for Slackware 14.1, and no longer requiring the Sort::Versions perl module, thanks to the work of pink_mist.

We’re also on github now:

So that’s pretty cool.

As usual, the source can be gotten from the downloads page.

As submissions are only recent opened on, I’m making the slackbuild available here as well:

sha256sum: 7176977a41997efaea9650004749c9e9cf2051134fd71aca00bd9787b1f4c45e

Nov 132013

I am happy – and at least somewhat proud – to announce the first release of a new Linux-based operating system called DavrOS. You can download this first release – 0.1 – via the downloads page.

DavrOS is not based on any existent Linux distribution – though it owes plenty to LFS, CLFS, BLFS, CBLFS, Slackware, and FreeBSD, amongst others.

Its primary goals include BSD/Unix engineering standards, application of lessons learned from BSD/Unix, POSIX compliance by default, and a simplified and robust approach. It includes the full OS source tree by default, from which an installation ISO can be easily generated so that an admin can trivially modify the source tree and generate an ISO with local changes as required.

As the version number implies, this release should be considered alpha at best. This release is to get the initial work out and about for testing and further development of the system. There is stuff missing, there are bugs, there’s plenty of work to be done still.

To install DavrOS, once the davros-0.1.iso is booted up, first utilize fdisk to setup your partitions; only MBR partitions are currently supported. Next, utilize mkfs.ext4 to create file systems; only ext4 file systems are currently supported. With these tasks accomplished, you can simply run “setup” to step through an interactive installer. Optionally run “setup” with any of the “-h”, “–help”, or “–usage” flags to see command-line options; anything specified at the command-line will proceed non-interactively and anything unspecified will proceed interactively, except installation of the source code which will assume yes unless the -S flag is present. Note that pkgsrc will not be installed regardless of the presence or absence of the -p flag, as it has not yet been implemented, and that the -N flag also does nothing for the same reason. I probably should have commented these options out of the help.

If installing on VirtualBox, the kernel parameter “intel_pstate=disable” is needed to avoid a panic.

To get the latest source code:
1. If the source was installed from the iso, rm /usr/src completely, then run “git clone git:// /usr/src”
2. If the source was installed previously from git, then “cd /usr/src && git pull”.
3. If the source was not previously installed, utilized the git command from the first case.

The DavrOS redmine page can be found here; the “Issues” page lists things we’re currently working on or which are on the to-do list. The “Wiki” page is largely a lot of thoughts and ideas, but also has the style guide which should be followed if looking to submit a patch or such. The “Repository” page provides web-based visibility into the git repo. The main page will tell you where to find us on IRC.

So get DavrOS installed somewhere and come find us.

Sep 222013

sbotools 1.7 is now released and works on -current; we removed all usage of the smartmatch operator which is experimental in perl 5.18. There are, unfortunately, no other real changes with this release; it only adds -current functionality.

We have not tied Slackware version 14.1 to the SBo 14.0 repository since the /etc/slackware-version in -current has not yet been updated to reflect the new version number. This means that if it is updated before 14.1 is officially released, sbotools will not work on -current at that time. We’ve also not tied 14.1 to 14.1, either, which means sbotools will currently break for 14.1 when it is officially released; we’ve not done this because we may have to change it prior to release, as noted above, in which case we’ll have to fix it at release time anyway – and since we do not know whether the version file will say 14.1 or 14.10 or something else again (but we think it will be 14.1…), we still run a good chance of having to fix it at release time.

The local changes are still planned but have not yet been actioned. We haven’t forgotten them, we’ve just been busy with other things. Such is life.

An updated slackbuild will be submitted to some time within the next day or so, but will take some time to get accepted there. In the meantime, you can grab the new source from and update the version number in the 1.6 slackbuild to rebuild and upgrade. Alternatively, once the new slackbuild is available on, you can simply run “sboupgrade sbotools”.

Mar 302013

Development has slowed on sbotools once again, which probably makes since given the size of the change-set for 1.5; this release is strictly a bug-fix release. Here are the highlights:

  • A bug where sbotools unsafely assumed the existence of /tmp/SBo has been fixed (this looked like “readdir() attempted on invalid dirhandle $tsbo_dh” with some other details afterward).
  • Support for $TMP being set in the environment has finally been implemented. SlackBuild files make use of this info, or fall back to /tmp/SBo; previously, we would not honour user changes to $TMP so all scripts used /tmp/SBo, which may not be what the user expects.
  • A bug where trying to install something which doesn’t exist threw a meaningless error has been fixed (this looked like “Odd number of elements in hash assignment” with some other details afterward).
  • A bug in the requirement checking code which could match something which was not a perl module against something installed via the cpan has been fixed.
  • A bug which would, in certain conditions, cause the queue to be generated out-of-order, which could cause builds to fail to sboinstall trying to build something before its requirement has been built, has been fixed. Thanks to W. Li for reporting this.

An updated slackbuild has been submitted to; you can either wait for it to be accepted there then use sboupgrade to update to 1.6 (if you have 1.5 installed), or you can download the slackbuild from there and modify it for 1.6 and use it to update manually.

The local-modification changes are still planned, just with one thing and another, they have not yet been gotten to, but unless we find some more stupid bugs first, that will be the next thing worked on. In theory…

sbotools on
sbotools on

Feb 142013

This release took a little longer as we finally felt that sbotools was in a sufficiently stable state as to be submitted to So, that’s the most obvious change, and it also means that, moving forward, sbotools will be able to upgrade itself. For this release, if you have a previous version installed, you will not be able to upgrade it using sboupgrade, since the tag for previous versions was _d4wnr4z0r instead of _SBo, meaning sbotools will not see an older version as an upgradable SBo; simply remove the old package and then install the new one. Beyond that, here’s a summary of the other changes in this version:

  • Proper varying exit statuses have been implemented to indicate the cause of the exit. Read the man page for a given command to determine its possible exit codes; if there are none documented, that command can only exit 0. If there are multiple errors, the exit code will be based on the last one encountered prior to exiting.
  • Several minor fixes in the way that sboupgrade and sboinstall operate.
  • If sboupgrade or sboinstall encounter an error, instead of simply stopping, they will ask if one would like to continue on. In some cases, errors encountered are not sufficient to stop other things from working, so this allows one to have the scripts continue on in order to do as much as can be done.
  • A bug where certain special characters in download links broke the downloading of those source files has been fixed.
  • A bug where an invalidly formatted file in /var/log/packages would cause sboinstall and sboupgrade to die has been fixed.
  • Previously sboupgrade and sboinstall, when set to “make clean”, as well as sboclean, had no knowledge of -compat32 stuff still lying around under /tmp; those items are now properly cleaned.
  • A bug where sbocheck would die if there were no updates, instead of exiting cleanly, has been fixed.
  • Several non-optimal sections of code have been optimized.

Moving forward, our next big thing is to implement a method of handling local modifications. We also have a couple bug reports to look into, and we’ll also be getting a wiki and some other fun things setup at some point.

sbotools on
sbotools on

Jan 062013

sbotools 1.4 is now released, yes, less than a week after 1.3, but we have a lot of small fixes and enhancements in this release. Not all are user-visible, but here are the ones that are:

  • When checking for installed requirements, sbotools is now aware of non-SBo packages. This means you can, for example, install jdk from /extra, and sbotools will see that as fulfilling an SBo’s requirement to have jdk already installed.
  • When checking for installed requirements, sbotools is aware of CPAN-installed Perl modules. Note that not all CPAN-installed Perl modules register themselves in the system’s perllocal.pod, so sbotools won’t know about them, and in some cases SlackBuilds of Perl modules rename the module in bizarre ways, and sbotools won’t know about such renamings.
  • A bug where attempting to build a compat32 package from something which had differing 32-bit and 64-bit download links would fail due to the slackbuild attempting to use the 64-bit source packages has been fixed.
  • The requirement to have Text::Tabulate installed for sbotools is no more.
  • sbocheck now writes a log, located at /var/log/sbocheck.log, of what updates it finds as available.
  • A bug where sbotools was no longer aware of installed compat32 packages from, due to a modification in how these packages get tagged, has been fixed.
  • A bug where sbotools could not always “make clean” the source directories, or would do an incomplete job of it, has been fixed.
  • sbotools will now attempt to download and md5sum verify all source files for all packages queued before attempting to build any of them.
  • A bug where if a source fail already existed but failed md5sum verification sbotools would not remove it before wget’ing a new copy, resulting in the new copy having .1 appended and the md5sum verification still failing, has been fixed.

As I mentioned last release, we’re a lot more organized now, and it has helped a lot.

Moving forward, we’re looking at the different ways we can go about supporting local modifications to the tree, implementing a wiki, doing some refactoring/rewriting/cleanups, and (probably the very next thing we’ll do) implementing a new testing method which we figure ought to expose a number of interesting bugs that we don’t even know about yet.


Dec 312012

sbotools 1.3 is here, and includes a new tool called “sboremove”; sboremove utilizes requirement information in the tree to provide the ability to easily remove an SBo along with all of its requirements. It is also aware of other installed SBos and their requirements and, by default, will not offer to remove any of a specified SBo’s requirements if another installed SBo shares any such requirements – though there is, of course, an option to have it do so.
Beyond that, there are a couple cosmetic bug fixes, as well as a fix for a bug which caused SBos specified to sboinstall which were also requirements of other specified SBos at the same time to show up multiple times in the install queue.

Moving forward, we’re starting to get a lot more organized now, which should positively impact not only the quality of sbotools but also the speed at which we can effect positive, beneficial changes to the codebase.