2 links pointing to ezine.daemonnews.org are no longer working.
As the whole daemonnews site is in rather bad shape at the moment (many broken
links over there) deactivate the links for the moment (but leave them in the
source code in case they come accessible again).
While here fix two other issues:
- Remove the entry "Install for Newbies" as there is no source mentioned
and as the article has been incorporated in the handbook a loooooooong time
ago.
- Ad "4.1" to the link about "Split DNS" as this is the FreeBSD version the
article describes.
this forum (and add a link to BSDnexus instead):
- the latest "news" are more than 2 years old.
- according to the users the have a massive spam problem on the server, too.
See also:
http://www.bsdforums.org/forums/showthread.php?t=57222&page=1&pp=15
Requested by: drhowarddrfine (drhowarddrfine att charter dott net)
- Move includes.nav*.sgml to share/sgml/navibar.ent and
<lang>/share/sgml/nabibar.l10n.ent.
- Move includes.sgml and includes.xsl to
share/sgml/common.ent, share/sgml/header.ent, <lang>/share/sgml/l10n.ent,
and <lang>?share/sgml/header.l10n.ent.
- Move most of XSLT libraries to share/sgml/*.xsl and
<lang>/share/sgml/*.xsl.
- Move news.xml and other *.xml files for the similar purpose
to share/sgml/*.xml and <lang>/share/sgml/*.xml.
- Switch to use a custom DTD for HTML document. Now we use
"-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension", which is
HTML 4.01 + some entities previously pulled via
"<!ENTITY % includes SYSTEM "includes.sgml"> %includes;" line.
The location of entity file will be resolved by using catalog file.
- Add DOCTYPE declearation to XML documents. This makes the followings
possible:
* Use of &foo; entities for SGML in an XML file instead of defining
{$foo} as the same content.
* &symbolic; entities for Latin characters.
- Duplicated information between SGML and XML, or English and
translated doc, has been removed as much as possible.
We haven't announced the release yet but the content is already
on the Web site, so adding a pointer to this won't really hurt.
Also it's one less thing to do when the time comes...
Not the release engineering team is responsible for
creating high quality packages but the ports management
team.
PR: www/94099
Submitted by: Kovesdan Gabor <gabor dot kovesdan at t-hosting dot hu>
Verified by: scotll