The 2.4 release looks to be about a week and a half away; if you’re a committer, please plan to make drastic changes after the release, if possible,
Category: Heads Up!
The libtiff package has been found to write out incorrect TIFF files in version 3.9.0. If that’s what is installed on your system, please update now.
Simon ‘corecode’ Schubert has removed GCC 3.4 and Kerberos 5/Heimdal from the base system. Kerberos hasn’t been building as part of base for a while, and is available in pkgsrc. It was also the last item that requires GCC 3.4, so buildworlds are little quicker now. (Cross your fingers that GCC 4.2 the current version doesn’t break somehow.)
As Hasso Tepper pointed out, having GCC 4.4 in DragonFly is unique to DragonFly. Systems like pkgsrc don’t work due to the changes in headers and etc. between gcc 4.2 and 4.4, and since no other BSD uses gcc 4.4, the fixes would all have to come from DragonFly (and be backward compatible). This is unlikely to change in the near term, since this newer version of gcc is being refused due to the V3 GNU Public License, not a technical issue. It’ll stay in DragonFly for now.
However, you can specifically exclude it and speed up buildworlds with the new NO_GCC44 option. It’s also possible to use NO_GCC34 in make.conf to keep the old version of gcc from building, for those who don’t like to wait.
DevFS breaks vinum. Will it be fixed? Yes, hopefully very soon.
DevFS has been added. There’s some issues, each with a workaround. Please test, as it’s certain that a major change like this will cause new problems around video and sound. Once those are fixed, however, device management will be a lot easier.
The DevFS Summer of Code project is going into DragonFly this weekend; be ready for surprises if you update. It’s not complete yet; there’s a few more weeks for Summer of Code, but there’s other work that this code will enable.
The kernel option PCI_MAP_FIXUP has been removed as of July 11th; if you’re upgrading past that point, make sure to remove that option.
There’s going to be a lot of kernel structure changes this week, as Matthew Dillon works on making more system parts multiprocessor-safe. Rebuild everything including your kernel, if you’re running bleeding edge DragonFly.
Hasso Tepper has a “BIG FAT WARNING” about two new issues: threaded programs are broken on bleeding-edge DragonFly because of a possible GCC bug that was only recently exposed, and Xorg in pkgsrc has issues with the Intel driver.
Simon ‘corecode’ Schubert already has one change in that may fix the issue with threaded programs, and is working on the Intel driver issue.
Update: more threading changes.
If you’re running bleeding-edge DragonFly, you’ll need to rebuild world and kernel after this recent change to interrupt counting from Sepherosa Ziehau.
If you’re a student with a Summer of Code application, make sure to subscribe to it. Doing this will ensure you are automatically notified of any mentor requests for more information.
There’s also some recent stats published by Google on the applications so far; DragonFly is one of the surveyed orgs it mentions, and the results are the same – less applications, better quality.
If you’re a potential student for Google’s Summer of Code, please get your application in ASAP. All student applications are due by 19:00 UTC April 3rd. You can revise a submitted application, even after the April 3rd cutoff, but it has to be in.
If you’re a student, you have from now until the 3rd of April to apply for a Summer of Code slot.
DragonFly BSD is a participating organization in Google’s Summer of Code 2009. (See the lists of participating organizations at the Google site.)
I have an announcement message with more details on the mailing lists; the next important date is the 23rd, when students can apply. If you’re a student, start putting your proposal together and talking with others. If you can mentor, sign yourself up on the Google site and request a mentoring spot.
Big news: Sepherosa Ziehau has managed to remove the Big Giant Lock from the ip and bridge forwarding path. This includes ipfw, though not yet pf. It is in fact possible to make the whole TCP/UDP code path BGL-free. Sepeherosa helpfully posted some benchmarks to show just how significant the improvements can be.
wiki.dragonflybsd.org has been set to be read-only, since the content has been moved to www.dragonflybsd.org. The site hasn’t been turned off yet, because I may have missed something in the move…
The iwi(4) firmware has been updated, and there’s an announcement that tells you where to find it.
If you are interested in the Google Summer of Code project, as a student, a mentor, or just want to suggest a project, write that down:
The application period starts for DragonFly (for the organization, not students) in a week, and it’ll help to see who wants to get in on the action.
Simon ‘corecode’ Schubert has some tips on how to mirror the git repo for DragonFly more exactly; there’s an additional command that can clean up spurious branches.
As Simon ‘corecode’ Schubert notes, DragonFly is now in a ‘Feature Freeze’ for two weeks. Please work on bug fixes in the intervening timeframe, and push them to the ‘master’ branch. Changes for the release will be pushed to the 2.2 release branch. Matthew Dillon has more details.
The ISC DHCP package in pkgsrc is changing as it moves from 4.0 to 4.1; the package names will be different, as will the rc flags. Keep an eye out for this if you use it for your internal network. (This may affect our install CD, too.)
Simon ‘corecode’ Schubert warns that a recent change in the size of struct thread is going to require a buildworld; this only affects people running DragonFly 2.1.
Somehow I missed this commit, but DragonFly 2.0.1 is out, with many changes to Hammer and other miscellaneous updates.
DragonFly 2.0.1 is going to be rolled this Wednesday, so if there’s anything you need in there, speak up.
Do you run a mirror?Â Make sure you’re downloading the 2.0 release ISO.Â The release won’t officially happen until there’s enough ISOs floating around for people to actually reach it.
If you want to commit something for 2.0, do it now!
If you are so inclined, test 2.0 building with a ‘cd /usr/src/nrelease; make installer release‘
It’s been 5 years since Matthew Dillon announced DragonFly. Happy 5th birthday, us!
2.0 is going to be released on the 20th.Â If you’re committing, make sure to put it both in the 2.0 and 2.1 branches, please.Â And get it in quickly!Â If you’ve contributed changes to this release, please get them listed in the 2.0 release document that Matthias Schmidt has been conscientiously updating.
The 2.0 release of DragonFly will be on the 20th of this month.Â I’ll be working on a new set of pkgsrc packages to match.
The upstream network provider for dragonflybsd.org is going through some changes, so there may be occasional downtime for some weeks.
I’ll link to my mailing list post about it, as I’ve already summarized there.Â Student signup is the 24-31st of March, so start getting it together if you want to be involved as a student or mentor!
HEAD users will need to do a full buildworld/buildkernel because of Sepherosa Ziehau’s recent changes to ifnet.
1.12 is being released Monday the 25th – test now!Â If something drastic comes up, Wednesday is the backup date.
Matthew Dillon found a memory corruption bug in sendmail; it is patched in the 1.12 release branch and in HEAD.
2.0 will be branched on the 9th and released on the 23rd of this month.Â If you have something you want in that release, hurry!Â HAMMER will be included in an alpha state.
Simonm ‘corecode’ Schubert has slipped the Preview tag; those of you running 1.11-preview can update and get all recent changes.
Matthew Dillon warns of struct vattr changes being done to support his new filesystem, HAMMER.Â This may cause problems in userland, though of course this can only affect you if you are running the bleeding edge of code.
Apparently Softpedia thinks DragonFly is up to version 1.2 and is yet another Linux distribution. Plus, their DragonFly article would be an exact copy of the DragonFly website’s main page text, if it wasn’t for the errors they added. (via Sascha Wildner)
Matthew Dillon found a problem in DragonFly with msdosfs mounts.Â He’s fixing it momentarily.
This is only a problem if you are running the very latest version of 1.11.
Since Matthew Dillon’s working on the disklabel code, be careful if you’re running bleeding edge code in the next few days.Â Disklabel errors eat data.
If you have a DragonFly system, you should update it now.Â (Point releases have been rolled for 1.8, 1.6, and even 1.4)Â Non-DragonFly systems should also be updated, if available.
The title says it all – visit the download page for 1.8 to get it.Â Most every mirror appears to have it right now – not just the ones on the 1.8 page.
Note that some sites have an early version of the 1.8.1 release that lacks the installer; that image is ‘dfly-1.8.1.iso.gz’.Â Instead, be sure to download ‘dfly-1.8.1_REL.iso.gz’, which should be the newer file of the two.
Sepherosa Ziehau warned bleeding-edge users that recent network interface changes will require a rebuild of both kernel and world when next updating.Â This does not apply to 1.8 users.
DragonFly 1.8.1 will be released this weekend, so if you have something that you need added, speak up!Â This release will include the rtld fixes that enable parts of KDE to work again, among other things.
You may need to copy in a new
/etc/localtime file to account for daylight savings time changes in the U.S. and Canada, especially if you have an older system; Matthew Dillon explains.
www.dragonflybsd.org and leaf.dragonflybsd.org are getting upgraded to 1.8; this may mean some intermittent downtime over the next week.
If you are running a DragonFly system older than version 1.6, and you are in North America using something other than UTC time, you will need to manually update your tzinfo files to reflect the changed (in 2005, taking effect this year) Daylight Savings Time start and stop dates.Â If you are on UTC or are running 1.6+, you are fine.
Matthew Dillon reports changes to the kernel configuration file are needed now.Â Also, if you are running bleeding-edge code, a full buildworld/buildkernel is required on the next upgrade.
Branching for 1.8 will happen very soon; as soon as ACPI is ready.Â The release date has not slipped.
Matthew Dillon is renaming some I/O calls.Â It shouldn’t cause major problems, but as always, make sure to do a complete buildworld/buildkernel when next upgrading your bleeding-edge system.
Matthew Dillon is making trapframe changes – it will require a complete buildworld if you are following bleeding edge code.Â Read his post for more details.
TLS system calls are being renamed by Matthew Dillon.Â If you’re running HEAD (bleeding edge code), this will require both a kernel and world rebuild on your next update.
Matthew Dillon is performing some significant cleanup of the kernel startup/VM code, so watch out if you are using the bleeding edge code.Â He synced Preview before starting, so Preview users can move to the code version just before this (potentially) destabilizing code.