A running description of activity related to DragonFly BSD.
Remember I posted that LibreSSL is in base DragonFly, but not default? Well, it’s default now. You can have a system without OpenSSL at all, by rebuilding DragonFly-current and using up-to-date dports.
Update: see John’s comments for clarification: LibreSSL is default; the change is that OpenSSL isn’t even built any more. The result is still the same good news: you can have an OpenSSL-free DragonFly system now.
How long does it take to build all 24,000 packages in the DragonFly ports collection? Apparently about 22 hours on a dual Xeon machine (with I think 36 cores) or 48-core Opteron. This is with synth. I used to measure pkgsrc builds in weeks.
DragonFly now has version 2.4.2 of LibreSSL and uses it in base. Ports may still link to OpenSSL, though – it’s still built by default, though make.conf can be configured to prevent that.
I don’t know how I ended up with 3 pfSense items to lead with – it just happened.
There’s been multiple reports of pulseaudio causing problems for DragonFly users. It would get pulled in as a dependency, and audio would suddenly stop working. Uninstall, and audio is fine. John Marino has removed it from dports, to prevent that exact problem.
Because this always happens just after I create a DragonFly release, there’s a new version of OpenSSL. However, this is for version 1.0.2. 1.0.1 is what’s in the release, and it’s supported through the end of the year.
OpenSSH has a major version bump in DragonFly, to 7.3p1. This means some features – specifically patches for High Performance Networking – are no longer there, and you’ll get an error if your config file requires them. Either remove the options from your config, or install OpenSSH from dports.
This is a specialized use case, but Mono 4.x has some issues on DragonFly. Some minor testing has been done, but if you are already using it, please contribute.
If you happen to be testing kernel modules, DragonFly can now load them from a modules.local directory. This keeps modules that aren’t part of the base system, separate. This is probably of most use to developers. It’s controlled by local_modules being set in /boot/loader.conf, and defaults to on.
(Updated for correct file location – thanks, swildner)
I see this bite people irregularly over the years: if your default shell on login can’t run, what do you do? I’ve seen it happen because of a missing /usr/lib, and it can happen with out-of-date library references, too. There’s several different ways to deal with it:
That last one may be useful if your dports setup gets mangled, somehow – though ‘pkg upgrade’ has always worked for me.
BSDNow 129 is available. Along with the normal news summary, it has an interview with John Marino, the fellow behind DragonFly’s dports system, and author of recently-noted-here synth, which has reached version 1.0.
If you’re building from dports, and you want to include debugging information, you’ll want to put ‘WITH_DEBUG=yes’ in /etc/make.conf. Note that this affects anything you build at that point, including world, which you’d want to rebuild anyway.
For those of you running DragonFly-current, the already-mentioned library privatization going on means that ports have to be rebuilt. You will want to do it yourself, or wait a little bit before upgrading if you want to install binaries.
That’s a pretty cryptic headline, isn’t it? John Marino has ‘privatized’ several libraries in DragonFly, so that they can’t get included involuntarily as part of a port build. That may mean you will need to perform a full rebuild of your system if you are tracking DragonFly-current.
(This is the way to fix ‘system’ languages like Perl was in FreeBSD 4.x – keep them clearly separate from the port version. It’s about a decade too late for that idea to work out, though.)
DMA, the DragonFly Mail Agent, is available in dports and FreeBSD ports, and is now available for NetBSD through pkgsrc-wip. (Thanks, Christian Koch)
John Marino has opened up his new utility for testing: Synth. It’s made for building custom package repositories, similar to poudriere, but much less setup work. If you’ve ever said “I like binary installs, but I want my own build options”, this is for you. The README includes screenshots to show all the things it can do.
John Marino has created two custom make variables – .MAKE.DF.OSREL and .MAKE.DF.VERSION. (They return the current DragonFly versioning, if you can’t tell from the name.) Apparently, if you build all 22,000 or so ports together, about 15% of the total time is just awk looking up the system version, and this removes that repeated task.
I am taking this moment away from my significant backlog of things to post to note that there have been a lot of games fixes in DPorts lately. Thanks to Rimvydas, many small bugs that kept games from compiling on DragonFly are now fixed. The easiest way to see is to look at the commits from December 8th and back, but the best way is to pick one and play.
Since DragonFly 4.4 has been branched, bleeding-edge DragonFly is now at version 4.5. As John Marino detailed in his post, that means pkg on 4.5 systems will look in a new place for downloads. (“dragonfly:4.6:x86:64”, since it always uses even numbers) To cover for this, set ABI to point at DragonFly 4.4 packages in pkg.conf for now. They’re freshly built and functionally the same, anyway. Once there’s a 4.6 download path, that ABI setting can be removed. Packages for DragonFly-current are available now and probably at the mirrors by the time this posts.
Update: as John Marino pointed out to me, anyone on DragonFly-master who upgrades now will be at version 4.5. This means pkg will get the new (4.5) packages on the next pkg upgrade. That means a mix of old and new packages unless you either reinstall anything (pkg update -f) or hardcode the 4.4 download path until you are ready to switch everything.
So: DragonFly-current users should either hardcode the 4.4 path for now or force an pkg upgrade for everything. DragonFly 4.2-release users are unaffected.
Imre Vadász has put together an initial port of Wayland / Weston for DragonFly. You can look at his pull request for dports to see how to install, though I’d imagine this is only for people who like to experiment at this point. It’s still work in progress, as is Wayland itself.
If you happen to still be running DragonFly 4.0 – that’s two releases ago and not supported – you may be noticing less ports are building. There’s been enough significant changes in DragonFly since that release that it’s reducing the number of buildable ports.
DragonFly 4.0 to 4.2 is not a difficult jump, so jump when you can. The converse of this, of course, is that there’s even more building on 4.2 and DragonFly-current.