I’m a bit late on this, but: If you are using DragonFly-current, you will need to rebuild world. If you are on 4.4, this won’t matter until you go to 4.6, and you’d be rebuilding world and kernel for that anyway.
(4.6 will probably be tagged this weekend.)
If you are running bleeding-edge DragonFly, Sepherosa Ziehau has made some networking changes that both reduce CPU usage in high-traffic situations and change some underlying network structures. This means a full buildworld is needed on your next update.
If you’re using DragonFly 4.4.x or older, you are unaffected.
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.)
Note: keep in mind this is a client bug – it’s an information leak when you as a client connect out to somewhere else. A server, as an endpoint, is not affected.
If you are using bleeding-edge DragonFly (4.3) on a machine with Intel video, the i915 module has been renamed. This means you will probably need to rebuild xf86-video-intel from source to have it match. There should be a matching binary package soon.
If you are on DragonFly 4.2, this does not affect you.
It has finally happened: There’s no more IPv4 addresses left to allocate, at least for ARIN – and that’s going to affect most people reading this. Ask your ISP for IPv6 access. The next step is being forced to implement either wonky 6to4 mappings, or just plain IPv6 networks.
If you were running a version of DragonFly 4.1 (i.e. the master version, not release) built between the 20th and 25th, rebuild. There’s a UFS bug introduced in that short timeframe.
If you are running 4.0.x release or built your version of DragonFly-master outside of that date range – you are unaffected.
DragonFly now has GCC 5.1 release. If you are running DragonFly master (i.e. 4.1), you’ll probably want to both rebuild world and kernel, and update your packages so they all match. There’s already packages built with GCC 5.1, so binary package upgrades can happen quickly. There’s GCC 4.7 packages still available if you aren’t making the jump yet.
If you’re on DragonFly 4.0.x – nothing’s changed.
The default compiler in DragonFly is going to change over from GCC 4.7 to GCC 5.x very soon, to match the GCC 5.1 release. This means that packages built for DragonFly-master won’t be compatible with the old ones. You will need to reinstall packages when you next ‘pkg install’. John Marino has an extensive writeup detailing what’s needed, and the actual change is some days off.
If you are using DragonFly 4.0.x (the release), this doesn’t affect you at all.
If you are on DragonFly-master and you upgraded during select hours on the 25th of February, you may have been bit by a makefile error. The fix, as listed in that link, is simple:
cp /usr/src/share/mk/sys.mk /usr/share/mk
If you are not on -master or you did not upgrade in that timeframe: never mind.
Well, might rather than will , but I had to make a music reference. There’s a bug in versions of pkg from 1.4.6(ish) to 1.4.11 that can make it accidentally delete itself while updating packages. If this happens to you, there’s an easy fix, as posted to users@:
# cd /usr && make pkg-bootstrap
Once you’re on version 1.4.12+, you’re fine.
Sepherosa Ziehau has posted a note that V4-mapped addressing is no longer supported in DragonFly. You will need to do a full buildworld/buildkernel if you are running master. Also, TCP MTU path discovery is on by default. Also also, he’s added a SOL_SOCKET/SO_CPUINT socket option for use to reduce load in heavy network activity. As usual, I don’t quite comprehend.
The 4.0 release of DragonFly is out! Quoting from the release page:
Version 4 of DragonFly brings Haswell graphics support, 3D acceleration, and improved performance in extremely high-traffic networks. DragonFly now supports up to 256 CPUs, Haswell graphics (i915), concurrent pf operation, and a variety of other devices.
The more eagle-eyed downloader will notice it’s version 4.0.1, not 4.0.0. That’s because
nobody trusts .0 releases I tagged 4.0.0 just before a few useful commits went in, and it’s better to retag to make sure everyone got them. See also my message to kernel@/users@
There’s a new bash vulnerability that could be a problem for a network-facing machine that happens to use bash. (See here for test.) As a BSD user, you can feel somewhat smugly superior since the default shell is tcsh and therefore it may not affect you – unless you’ve installed it from dports.
John Marino has already updated dports. A new binary is forthcoming, though you can always rebuild by hand if you don’t want to wait.
Update: oh, wait, not done.
If you are on DragonFly, using pf, using altq, and using fairq to control usage, there’s a latency bug that Matthew Dillon recently fixed. He’s posted an announcement and committed fixes to master and 3.8, so it’s only an upgrade away.
Because of some structure changes made by Matthew Dillon while chasing a pf bug, you will need to do a full buildworld/buildkernel on your next update – if you are running DragonFly-master. 3.8 users are unaffected by the bug or the change.