A running description of activity related to DragonFly BSD.
The short answer is: works great. The version in dports lags, cause it’s based on what’s in the FreeBSD package collection, and that’s not updated as quickly.
This is technically the prerelease, since the official one is a few months off. TeX Live binaries can be downloaded directly for DragonFly.
This happened a little bit ago but I wanted to be able to post a solution to the pkg upgrade issue (yesterday) before mentioning it: there’s a freshly built batch of packages for DragonFly, so now is a good time to upgrade with pkg.
If you upgrade pkg on your system, it may start erroring out. This is because the default config will confuse the newer version. To fix this, you can copy over a working config and the problem will go away. I expect this may only be a problem until the next release.
If you delete all your installed packages, you will also lose the certificate used by pkg to verify the connection to download new ones. There’s several workarounds for this problem.
A complete set of new dports binaries have been built, for 5.8 and for -current, so now is a good time to upgrade. Update to 5.8.3 if you haven’t yet, while you are at it.
Here’s a recommendation (and a usage lesson) on pkg-provides, a tool for matching a file to the installed pkg that brought it. It goes with the pkglocate article some weeks ago; it seems like this should be standard functionality. Thanks to Nelson H. F. Beebe.
As part of installing DragonFly, Jonathan Engwall happened to create a script to install every part of xfce4 that he wanted. I’m linking to it in case you want it too.
(xorg and web browser install not included)
A note for the future: if pkg itself isn’t working, you can use pkg-static.
This is I think not resolved yet, but here’s something I didn’t know: keeping Chromium from being tied into Google’s services is actually a build issue, not a settings issue. i.e. once it’s in binary form, you can’t opt out.
On EFNet #dragonflybsd, Matthew Dillon and ‘mjg’ have been discussing various way to optimize for bulk builds. A recent update from mjg for different memory functions shaved 1.7% off bulk build time – significant, when you are talking tens of thousands of packages.
daemon(8) has been updated, cause there’s ports that expect daemon to have some specific flags – especially -T.
There is a certain correlation between this utility and certain BSD logos.
If you installed BSDStats but it didn’t work, here’s why – with a fix.
It’s probably going to be quiet for at least a few days because of the Christmas holiday, though I’ll of course have the normal weekend features up.
In the meantime, here’s something to ponder: this post about tmux and plugins for it led me to thinking about plugins in general. The pkg system is sort of a plugin scheme for BSDs, much like apt for Debian, yum, etc. Each language has its own libraries to load and plugins to manage past that, like Perl’s CPAN. Nowadays, applications have their own plugins. For instance, a system with WordPress installed with PHP installed with PHP plugins required with WordPress plugins that also require given PHP libraries. WordPress manages keeping itself and its plugins up to date, but not the underlying PHP installation. You can get something similar with Perl along with the Perl-specific package updates, through cpanm. Or, npm, which seems to be its own world of constant flux.
How many levels could this go? Like running multiple emulators within each other, how many levels of plugin could you achieve? There’s probably a series of levels proceeding from tedious to barely maintainable to ridiculous.
Synth logs for dports are now located here on a new machine:
https://sting.dragonflybsd.org/dports/logs/Report/
If there’s only a short list, it’s because the most recent build was probably focused on retrying a broken-but-now-possibly-fixed package. I link both because of the utility and also because the interface is pretty.
There’s been a fresh binary build of dports – and then some more updates to cover a variety of security issues in some of those ports. Now is a good time for a ‘pkg upgrade’.
Some of the larger application sets on DragonFly have had trouble building, and inconsistent problems with that build. i.e. rust would fail, but in different parts of the build process, every time. It looks to be a problem with signal interaction, and there’s now much safer ways to do that on DragonFly.
That is going to require a full buildworld/buildkernel if you are on DragonFly-master, 5.7. Release/5.6 users are unaffected.
Remember how I said dsynth defaults to txz (tarred, XZipped) ? I was apparently wrong and it was using tgz (tarred, gnuzipped). Now it really truly defaults to txz, for space.
Pluggable Authentication Modules on DragonFly have gone through some changes. pam_ssh has been removed, along with pam_tacplus, and pam_radius, in favor of the more frequently updated versions in dports. ppp(8) still supports radius, though.
You should set hostname in /etc/rc.conf. I am mentioning this now because not doing it kept me from running X apps from a DragonFly system on a Windows 10 system with vcxsrv, and I wasted half an hour of my life figuring that out. Apparently this is a lesson I need to keep relearning.