Joerg Sonnenberger has placed gcc-3.4.3 into DragonFly; it is still considered experimental, so use it by setting the environment variable CCVER to ‘gcc34’ only after careful thought. His post has other details.
FreeBSD 4.11, the final release in the FreeBSD-4 series, is due around the end of January. The next official release of DragonFly will probably be out soon after, which makes a handy upgrade path if you are trying to avoid the FreeBSD-5 experience.
Joerg Sonnenberger warned that several drivers will be removed in the next two weeks from all flavors of DragonFly, including Stable, unless someone needs them:
– GPLed math emulator
– GPLed dgb driver
– GPLed awe driver
– old pre-newbus rp driver (use nrp instead)
– OLDCARD AKA pcic (also not built as module by default)
The Stable tag has been moved up to the most recent code, as some critical fixes required what’s in the most recent code. In general, this should only be positive, unless you are using unionfs or nullfs, as they will be broken if you upgrade. So, if you are using those file systems, hold off on upgrading for a few weeks. When you do upgrade, it has to be a full buildkernel/buildworld.
Matthew Dillon reported a hard disk failure knocked out the DragonFly website and mailing lists over the weekend; there’s a new disk, filled from backups, back in place now.
Matthew Dillon reported that he and David Rhodus have tracked down and eliminated a longstanding bug that caused VM/filesystem corruption, dating from FreeBSD 4, which may even still be present in FreeBSD 5.
As a side effect, Matthew Dillon’s VFS work will get pushed into the most current code (HEAD). Unionfs and nullfs work has not been completed in the VFS code, so that means if you use HEAD and also use unionfs/nullfs, either don’t update for the next week or so, or drop back to DragonFly_Stable.
Matthew Dillon posted about some changes to the way the mailing lists work; this is to avoid the ever-increasing spam that has been coming in. The short summary is that is you post through news, or use your subscribing address when posting mail, it should work normally. Otherwise, read his plan further.
Matthew Dillon wrote that the DragonFly_Stable tag is being moved up to the current code, as his potentially destabilizing VFS work is going to be going into the tree, starting tomorrow.
The moral: if you have production or near-production machines, stick with the stable tag, for now.
Joerg Sonnenberger warned that a full buildworld will be needed when next upgrading your system. You will also want to recompile any ports that use cam/libcam, like many CD-reading tools.
Joerg Sonnenberger has commited a whole pile of updates to various network drivers, among them axe(4). He warns that anyone with a axe(4) device should give it a whirl, as the driver is untested at this point.
MAtthew Dillon warned that the ongoing VFS work will make the use of buildkernel/installkernel absolutely necessary for kernel installation, for anyone using filesystems other than those built into the kernel.
Due to a typo, now fixed, in the disklabel man page, the Installer for DragonFly 1.0A used a too-large fragment size for disks larger than 1G. You may run out of inodes depending on the size of your disk and the number of files you have on it. Matthew Dillon suggested this temporary workaround when installing, until the Installer is changed.
Matthew Dillon noted that a full make buildworld/kernel and installworld/kernel is needed on the next update, due to a number of changes he has made.
If you haven’t updated recently to catch the scheduler changes, you may want to do this in any case.
forknibbler.com is down; that’s where I host builds of material that is in doc CVS. It’ll be up as soon as I can get to the physical location.
There’s a new image available that fixes the installer problem when installing to a partition that isn’t the last one on the disk.
Quoted from the download page:
IMPORTANT ERRATA ADDENDUM: Using the installer on a multi-slice disk will improperly resize the target slice when it is not the last slice, to be the same size as the last slice, leading to a corrupt disk! We will have an update to fix this problem in the next 24 hours!
Matt Dillon posted an announcement about 1.0RC1 last night on the kernel mailing list; it contins some important notes about ACPI.